These tests are using FileCheck to check the result of diagnostic
formatting in ways that don't match the new formatter. Force the old
formatter or, where possible, generalize so that they match both
formatters.
Thsi diagnostic currently emits, for example:
```
could not find module Foo for target arm64; found: x86_64
```
It is sometimes very useful to know where exactly the `found` module is located, so this PR changes this diagnostic to emit:
```
could not find module Foo for target arm64; found: x86_64, at:
<Path where Foo.swiftmodule/x86_64.swiftmodule is located>
```
When loading a module supporting multiple targets, the module loader now looks for a file named with a normalized version of the target triple first, and only falls back to the architecture name if the normalized triple is not found.
This diagnostic needs to be adapted for swiftinterfaces too, but
meanwhile let's not have it get in the way when dealing with a
multi-architecture module that has parseable interfaces.
MyKit.framework/
Modules/
MyKit.swiftmodule/
x86_64.swiftinterface
x86_64.swiftdoc
# no x86_64.swiftmodule
armv7, armv7s, and armv7k all get encoded as "arm" in today's scheme
for swiftmodules, so we can't just use the CPU part of the triple as
the expected swiftmodule architecture in the diagnostic.
