fix(derive): Allow subcommands to directly nest in subcommands

[epage]

structopt originally allowed

#[derive(Clap)]
pub enum Opt {
  Daemon(DaemonCommand),
}

#[derive(Clap)]
pub enum DaemonCommand {
  Start,
  Stop,
}

This was partially broken in #1681 where $ cmd daemon start works but cmd daemon,
panics. Originally, structopt relied on exposing the implementation
details of a derived type by providing a is_subcommand option, so we'd
know whether to provide SubcommandRequiredElseHelp or not. This was
removed in #1681

With this change, the above code is now:

#[derive(Clap)]
pub enum Opt {
  #[clap(subcommand)]
  Daemon(DaemonCommand),
}

#[derive(Clap)]
pub enum DaemonCommand {
  Start,
  Stop,
}

This can be taken a step further and support optional subcommands in variants like we do fields. That kind of consistency would help in people feeling confident in using the derives.

To implement this, I made it so we no longer re-used attribute validation between struct/enum and variants but instead we have variants broken out separately, like with fields. I tried to ensure the error validation was correct for struct/enum and variants. I think for struct/variant, we only want the default Kind, assuming Flatten and ExternalSubcommand were allowed for variant sake. I didn't see why FromGlobal was allowed on struct/enum/variant, so I made it error in both cases.

Depends on #2586

Fixes #2005

[epage]

Until #2586 is landed, see the individual commit for reviewing whats relevant for this PR.

[epage]

The mac job got canceled for some reason

[epage]

Rebased