Use Disjunction Constraint to find main function

[etcwilde]

Third time trying to get the main function resolution behaving correctly.
The challenge here is that, unlike other functions, we don't have a way to determine whether the "calling context" of the main function is synchronous or asynchronous because there isn't a calling context. It is up to the main function to determine whether the rest of the program is run from a sync or async context.

The last two designs didn't work correctly for various reasons.
Simply making the constraint solver ignore async/sync mismatches results in incorrect behavior with conditional conformances. The following snippet exposed the issue. The original resolver would fall back on grabbing the first candidate from the list of candidates if no best solution was found. A best solution wouldn't be set if there were ambiguities or missing functions. The candidates were in the order of declaration in the source file. So in this case, if you selected configuration 3, it would see the ambiguity between the synchronous and asynchronous main function, and select the main function in config 1. (This is bad!) It should instead report the ambiguity.

@main
struct MainType : App {
#if CONFIG1
    typealias Configuration = Config1
#elseif CONFIG2
    typealias Configuration = Config2
#elseif CONFIG3
    typealias Configuration = Config3
#endif
}

protocol AppConfiguration { }

struct Config1: AppConfiguration {}
struct Config2: AppConfiguration {}
struct Config3: AppConfiguration {}

protocol App {
    associatedtype Configuration: AppConfiguration
}

extension App where Configuration == Config1 {
    static func main() { print("Config1") }
}

extension App where Configuration == Config2 {
    static func main() async { print("Config2") }
}

extension App {
    static func main() async { print("Default Async") }

    static func main() { print("Default Sync") }
} 

To mitigate this, I tried using an async-main flag, which would bias the constraint solver in favor of one over the other.
This was not ideal for a few reasons. While it resolved the above case with the explicit flag, it first, required an explicit flag that would completely change the behavior of the program, but second, would prefer either the sync or async function of the specific type. e.g, in the above case, if you specified Config1, with the async flag selected, it would choose the default async main function instead of the function from Config1.

In order to actually fix this to be properly sane, I've done a bit of digging with the constraint solver. Rather than dragging out everything called main, then trawling the list of everything we found, I've set up a disjunction constraint of only the types and names of valid main functions. This way we only get a list of valid function declarations, with a valid type, called main. The valid types are () -> Void, () async -> Void, () throws -> Void, () async throws -> Void, @MainActor () -> Void, @MainActor () async -> Void, @MainActor () throws -> Void, and @MainActor () async throws -> Void.

[etcwilde]

@swift-ci please test

[etcwilde]

@swift-ci please test

[etcwilde]

@swift-ci please test

[DougGregor]

Look

[DougGregor]

Is this the only expected behavior change?

[etcwilde]

There's more behavior change here than just the ambiguous resolution with both main functions.
The bigger change here is that we always resolve the most specific main function regardless of whether it's async or sync without needing the flag to bias things.

[etcwilde]

@swift-ci please test