Support for context-specific App functions

[epage]

App::help_heading applies to all future args being added. We expect to add more like this (App::next_display_order, `App::env_prefix).

The challenge will be to fit it in the data model.

[epage]

An option based on #24

name: myapp
version: "1.0"
author: Kevin K. <kbknapp@gmail.com>
about: Does awesome things
args:
    - name: config
      short: c
      long: config
      value_name: FILE
      help: Sets a custom config file
      takes_value: true
    - name: INPUT
      help: Sets the input file to use
      required: true
      index: 1
    - app:
        help_heading: DEBUG
    - name: verbose
      short: v
      multiple: true
      help: Sets the level of verbosity
subcommands:
    - test:
        about: controls testing features
        version: "1.3"
        author: Someone E. <someone_else@other.com>
        args:
            - debug:
                short: d
                help: print debug information

In effect, the data model for args is

struct App {
    ...
    args: Vec<ArgEntry>,
}

#[serde(untagged)]
enum ArgEntry {
    App(AppArg),
    Arg(Arg),
}

struct AppArg {
  app: AppArg2
}

struct AppArg2 {
    help_heading: Option<String>
}

(Ok, I got less creative with names as I went)

[aobatact]

Is this clap-rs/clap#3002?

[aobatact]

What is the difference between AppArg and Arg?

[epage]

Parts are in clap-rs/clap#3002 and in other issues.

AppArg exists for forcing the app key to be present since ArgEntry needs to be untagged.