@swift-ci create

This seems to be compiler behavior, with special-casing for a single source file vs multiple, and also special-casing of the file name "main.swift". There is a `-parse-as-library` flag that SwiftPM can pass but then "main.swift" will stop being recognized as an entry point:

❯ swiftc -parse-as-library -c main.swift

main.swift:1:1: error: expressions are not allowed at the top level

I'm not sure what SwiftPM can do here without some help from the frontend.

Perhaps the compiler can have a flag that SwiftPM and other build systems can use to convey the intent that "this is intended to be an executable module, i.e. there should at the end be a single entry point from either a main.swift or a @main, please emit an error if that's not the case".

Perhaps something like `-parse-as-executable`? Leaving off the flag would have today's heuristics, but passing either `-parse-as-library` (with today's semantics) or `-parse-as-executable` (with new semantics roughly like above) would specifically convey intent, allowing the compiler to have better diagnostics than just leaving it to the linker to report the absence of a `_main` symbol?

In the meantime, I think SwiftPM will need to apply some heuristics to counteract the compiler's. We can't just pass `-parse-as-executable`, because then `main.swift` will stop working, but maybe we can look for the last path component of all of the source files, and unless one of them is `main.swift`, we pass `-parse-as-executable`.

I put up at PR at apple/swift-package-manager#3410 for SwiftPM to mitigate this by passing `-parse-as-library` when there is just one source file in the module and it isn't named `main.swift`. For better ergonomics, I suggest what I mentioned above, so that SwiftPM and other build systems can convey their intent to the compiler, and it can disable its heuristics and use that intent for diagnostics (e.g. emit an error if there is no entry point at all when a single entry point was expected, etc).

Merging with SR-12683