Properly handle toolchains from Command Line Tools on macOS

[matthewbastien]

Description

Adjust toolchain discovery to detect which tool manages the swift binary that was found in PATH. This allows us to delegate to the appropriate tool when trying to find toolchain executables. Possible toolchain managers are:

• xcrun: Toolchain was either installed via xcode-select --install or by downloading Xcode. Executes xcrun --find swift to find the path to the toolchain. Only available on macOS.
• swiftly: Toolchain was installed via swiftly. Executes swiftly use --print-location to find the path to the toolchain.
• swiftenv: Toolchain was installed via swiftenv. Executes swiftenv which swift to find the path to the toolchain.
• unknown: A toolchain manager was not recognized. The path to the toolchain is assumed to be two levels above the path to the swift binary in PATH.

Detecting toolchains that need xcrun is done by performing an objdump on the swift binary and looking for an __xcrun_shim data segment. If one is found then we know that we have to use xcrun when querying for toolchain executables even if the path to the toolchain does not live within an Xcode.app. This makes the toolchain detection logic more resilient instead of using brittle heuristics that only look at the toolchain path.

Issue: #1077

Tasks

• Required tests have been written
• [ ] Documentation has been updated
• Added an entry to CHANGELOG.md if applicable

[award999]

Some initial comments but this is fairly large so we should get some more eyes on it

[award999]

Did this serve a purpose beyond making the assertions below easier? If not then it's in place now I guess but in the future we should do these in a separate tech debt PR to cut down on the noise in this bug fix. I assume there are a lot of cases across our tests that could have made use of this that are going to be missed

[matthewbastien]

I can split this into a separate PR if we want. Some code paths use path.resolve() which changes the slashes to the current platform while others don't. This meant that certain tests would need to handle this while others didn't (and it isn't obvious why when looking at the test code). I wanted a consistent way to check for path equality.

[award999]

If you set swift.path to <home>/.swiftly/bin or whatever the path is, swiftly was getting resolved as the swift binary so just want to make sure we didn't regress there