Unfortunately, we can't track using a `ValueParser` inside of `Command`
because its `PartialEq`.  We'll have to wait until a breaking change to
relax that.

Compatibility:
- We now assert on using the wrong method to look up defaults.  This
  shouldn't be a breaking change as it'll assert when getting a real
  value.
- `values_of`, et al delay panicing on the wrong lookup until the
  iterator is being processed.

To set the type, we offer
- `ValueParser::<type>` short cuts for natively supported types
- `TypedValueParser` for fn pointers and custom implementations
- `value_parser!(T)` for specialized lookup of an implementation
  (inspired by clap-rs#2298)

The main motivation for `value_parser!` is to help with `clap_derive`s
implementation but it can also be convinient for end-users.

When reading, this replaces nearly all of our current `ArgMatches` getters with:
- `get_one`: like `value_of_t`
- `get_many`: like `values_of_t`

It also adds a `get_raw` that allows accessing the `OsStr`s without
panicing.

The naming is to invoke the idea of a more general container which I
want to move this to.

The return type is a bit complicated so that
- Users choose whether to panic on invalid types so they can do their
  own querying, like `get_raw`
- Users can choose how to handle not present easily (clap-rs#2505)

We had to defer setting the `value_parser` on external subcommands,
for consistency sake, because `Command` requires `PartialEq` and
`ValueParser` does not impl that trait.  It'll have to wait until a
breaking change.

Fixes clap-rs#2505

Still unsure what should be the default but this at least makes it
easier for people to choose.

In theory, directly implemented types should have higher precedence than
inferring from another trait.

This will let us replace `Arg::possible_values` completely by letting
completions check these.

This identified a problem with the blanket implementations for
`TypedValueParser`: it only worked on function pointer types and not unnamed
function tupes.  The user has to explicitly decay the function type to a
function pointer to opt-in, so I changed the blanket impl.  The loss of
the `OsStr` impl shouldn't be too bad.

This gives a little more implementation flexibility

Fixes clap-rs#3621

This gives us more implementation freedom for the future.

This allows reducing the use of `Clone`, especially in `clap_derive`.

This makes life easier for people, whether they want a geneirc
`NonEmpty<impl TypedValueParser>` or a `PathBufExists(PathBuf)`.

There are several approaches with this
- `value_parser(N..M)`: creates an i64 range
- `value_parser(value_parser!(u16).range(10..))`: creates an u16 range
  that starts at 10
- `RangeI64ValueParser`: create whatever range you want

I was hoping to generalize `RangeI64ValueParser` for any source type,
not just i64, but ran into issues and decided to punt.  I chose `i64` as
the source type as it seemed the most general and didn't run into
portability issues like `isize`.

This is a step towards clap-rs#3199.  All that is left is for the derive to use
this.

This is needed for `Bound::cloned` and fits within official MSRV policy
(2 versions back) and unofficial (6 months, see clap-rs#3267)