The idea behind storing a StringRef was to reduce the memory footprint because we made the assumption that a `ModuleSearchPath` always outlives the `SearchPathOptions` it was created from. What I did not consider was that the path was referencing into a `std::vector`, which could get resized, thus invaliding the memory the `ModuleSearchPath`’s `StringRef` was pointing to, causing memory corruption.
To fix this, store the path string inisde the `ModuleSearchPath` itself. Since we store a `ModuleSearchPath` for every file inside that module search path in the `LookupTable`, by itself this would cause a new copy of the path to be stored for every file inside a module search path. To avoid this, make `ModuleSearchPath` ref counted and only store a reference to one shared `ModuleSearchPath` entry in the lookup table.
rdar://88888679
When looking for a Swift module on disk, we were scanning all module search paths if they contain the module we are searching for. In a setup where each module is contained in its own framework search path, this scaled quadratically with the number of modules being imported. E.g. a setup with 100 modules being imported form 100 module search paths could cause on the order of 10,000 checks of `FileSystem::exists`. While these checks are fairly fast (~10µs), they add up to ~100ms.
To improve this, perform a first scan of all module search paths and list the files they contain. From this, create a lookup map that maps filenames to the search paths they can be found in. E.g. for
```
searchPath1/
Module1.framework
searchPath2/
Module1.framework
Module2.swiftmodule
```
we create the following lookup table
```
Module1.framework -> [searchPath1, searchPath2]
Module2.swiftmodule -> [searchPath2]
```
