Implement Subcommand Autodiscovery

[Azoy]

This is an initial draft of subcommand auto discovery using reflection to find a list of protocol conformances to ParsableCommand and looking for nested types who conform to said protocol.

I haven't added any new tests, but I've changed some of the existing tests which essentially tests this functionality. There are still tests who have subcommands who aren't nested, thus they still use the subcommand array in CommandConfiguration which allows us to test that user defined subcommands also still work. If specific tests are needed, I'll be happy to add them! This is marked WIP because there are still some more documentation needed to fully explain this feature.

Checklist

• I've added at least one test that validates that my change is working, if appropriate
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary

[Azoy]

@swift-ci Please test

[Azoy]

@swift-ci Please test

[kylemacomber]

This is so cool!

[Azoy]

@swift-ci Please test

[Azoy]

error: unexpected platform condition (expected 'os', 'arch', or 'swift')
#if _ptrauth(_arm64e)

Um, excuse me? (This has compiled in the past, and the stdlib makes use of this conditional as well??)

Edit: Seems the ci bot is using Swift 5.2.4 and this conditional wasn't released until 5.3

[kylemacomber]

We should probably leave at least one test that explicitly lists out the subcommands and/or we should add a test that explicitly lists out the subcommands (and deliberately omits a nested ParsableCommand)

[natecook1000]

This is looking great, @Azoy! 👏🏻👏🏻

In addition to the notes below, let's make sure we still have tests covering manually specified subcommands as well as the empty override (a command with nested subcommands, but with subcommands: [] as part of the configuration).

[hassila]

@Azoy Did/would you consider splitting out _Runtime & _CRuntime to a separate GitHub SPM package? I'm starting to look at prototyping a dynamic loading plug-in API (https://forums.swift.org/t/swift-dynamic-loading-api/39495/21) and I think the approach you took there would be a possible nice way forward for that use case too. I was thinking of linking the plugins with that hypothetical separate package with the metadata runtime to allow for fully dynamic discovery of types conforming to the specific API protocol. It seems like generically interesting introspection capability...