In experimenting on #1772, I want to write test cases for various
combinations of required or not, values vs occurrences, etc. There
wasn't really a clear place to put these.
On top of that, I wanted there to be a clear place in the tests for
describing the behavior of special types, to make it easier to audit and
easier to see how a PR for #1772 changes things.
As part of this effort in organizing these tests, I reduced the number
of tests that use special types. This better focuses these tests on the
cases they are intending to cover, rather than pulling in unrelated
features. This makes it easier to audit special types and makes it so
failures give more focused results, making it easier to see what broke.
Before #2005, `Clap` was a special trait that derived all clap traits it
detected were relevant (including an enum getting both `ArgEnum`,
`Clap`, and `Subcommand`). Now, we have elevated `Clap`, `Args`,
`Subcommand`, and `ArgEnum` to be user facing but the name `Clap` isn't
very descriptive.
This also helps further clarify the relationships so a crate providing
an item to be `#[clap(flatten)]` or `#[clap(subcommand)]` is more likely
to choose the needed trait to derive.
Also, my proposed fix fo #2785 includes making `App` attributes almost
exclusively for `Clap`. Clarifying the names/roles will help
communicate this.
For prior discussion, see #2583
