feat: add require no space to argument short version

[my4ng]

Fix #3030.

This PR enables restricting the short option to the -oval syntax with the require_no_space argument setting, and changes require_equals to only affect the long option --option=val (BREAKING CHANGE). This will allow compliance with the POSIX and GNU conventions as mentioned in the issue by setting both require_no_space and require_equals to true:

In clap terms, these are saying we should only allow

• --long
• --long=value
• -s
• -svalue

Here is an example help message that demonstrates this:

Usage: myapp [OPTIONS]

Options:
  -f[<foo>], --foo[=<foo>]  This is foo
  -h, --help                Print help

A specific real-world application that has motivated this is uutils/coreutils which aims to mirror the GNU version as closely as possible. However, their date -I/--iso-8601 implementation, for example, accepts values that are not considered valid (e.g. date -I seconds and date -I=seconds), and there is no possible workaround.

The changes made to require_equals may break current applications that take a positional argument after an optional option-argument, e.g.

Command::new("prog")
    .arg(
        Arg::new("cfg")
            .action(ArgAction::Set)
            .require_equals(true)
            .num_args(0..)
            .short('c'),
    )
    .arg(Arg::new("cmd"))
    .try_get_matches_from(vec!["prog", "-c", "cmd"]);

Currently cmd would be treated as the second argument, but after the PR where require_equals no longer works on short option, it will become the associated value to the first.

Migration to the new major version (if this is merged) should complement require_equals with require_no_space and replace -o=val usage with -oval, otherwise the associated value would become =val as = is parsed as part of the value.

[epage]

Thank you for your interest in this and the work that you put into this! However, we are not ready to make a breaking change at this time and we have not fully decided on a direction for this. I would instead recommend you propose your idea in the thread of #3030 and see where that goes. As this is too early for this PR and its unclear if this is the PR that we want, I'm going to go ahead and close this for now.