App::about and Arg::help are inconsistent

[epage]

We have App::about, Arg::help and PossibleValue::help.

Should these be more consistent?

See a prior discussion for more context

---

Original Issue after #17

Transfered from clap-rs

When a user "knows" what they are looking for, they browse directly to it. As a user with clap3, when I'm looking to set the help description for an argument, I'm looking for help something in the Arg table of contents, but it wasn't there until beta.5 and its deprecated (Issue: clap-rs/clap#1823, PR: clap-rs/clap#1840). So in a way, clap-rs/clap#2718 has been helping but its of limited time until the next major release.

We have conflicting needs:

• We want consistency within clap so its easier to move from one piece to another (the old Arg::help is analogous to App::about)
• We want to be clear in our terms (does help refer to just a help description or the entire help, especially a problem in App)
• We want to be discoverable
  • Which about hasn't been for me
  • In terms of past clap users, "do nothing" is discoverable
  • In terms of past structopt users, they don't care since they use doc comments :)
  • In terms of what people might be familiar with:
    • python's argparse's equivalent is App::description and Arg::help
    • golang's kong's equivalent is App::description and Arg::help
    • cpp's boost::program_option's equivalent is Arg::description
    • rust's gumpdrop's equivalent is Arg::help

The question is what do we prioritize and how should we resolve this?

I figured a discussion would be more appropriate rather than trying to lump this in with clap-rs/clap#2164