build: support building against Foundation.framework

[compnerd]

This enables building XCTest against the System Foundation.framework on
macOS. This requires that the executable path is computed using URL
(NSURL) as the lastPathComponent has been explicitly made
unavailable.

/Users/compnerd/SourceCache/swift-corelibs-xctest/Sources/XCTest/Public/XCTestMain.swift:99:48: error: 'lastPathComponent' is unavailable: Use lastPathComponent on URL instead.
        let exeName = CommandLine.arguments[0].lastPathComponent
                                               ^~~~~~~~~~~~~~~~~
Foundation.StringProtocol:7:16: note: 'lastPathComponent' has been explicitly marked unavailable here
    public var lastPathComponent: String { get }
               ^

[compnerd]

@swift-ci please test

[compnerd]

CC: @briancroom

So, with this work, I can actually build XCTest easily on macOS. This has the benefit of being able to easily write tests for macOS/Linux/Windows as XCTest on macOS does not have XCTMain and testCase available in Swift. There isn't a XCTest runner on Windows, and on Linux, you either need to use either swift-package-manager to generate the scaffolding or use XCTMain. So, on Windows and Linux (to run from the command line) you need that. On macOS, you need to build up the bundle if you want to use XCTest from the system. For a little bit more work, you can have the same code run on all three platforms from the console without having to setup the bundle.

[stmontgomery]

This seems fine to me, and I see CI has succeeded on both macOS and Linux. @briancroom feel free to jump in if you object, or have follow-up comments to this in relation to the previous PR

[briancroom]

Ok, cool. Yeah, I think using SwiftPM as the cross-platform workflow entry point is the recommended path, but if you find it helpful/convenient to be able to use Corelibs XCTest on macOS, I don't see any particular reason to put up roadblocks for that.