Decide on a standard for command help formatting

[myk002]

• Decide on minimum structure required for every command (e.g. 1-3 sentences of description, Usage, Examples (if there are any params to use as examples))
• Decide on formatting to use for Usage and Examples sections, including how the syntax is expressed to the user, formatting for subcommands, formatting for parameters, how valid options for parameters are communicated, etc.

For consistency, long parameter names in documentation should all be prepended with two dashes (e.g. --longparamname) and single-letter options should be prepended with a single dash (e.g. -a). Scripts that use argparse.processArgsGetopt() already follow this convention. Scripts that use argparse.processArgs() treat options with either one or two dashes the same, so no code changes will be required there. Scripts that hard-code string matching will need to be updated.

Reviewing the commandline parameters themselves and standardizing exactly how each command structures its options is out of scope for this issue.

The standard should be tested on a variety of existing help text (e.g. simple ones like unsuspend, medium ones like devel/query, and long ones like quickfort) before being applied across our documentation.