cli: improve output and consistency for unknown (sub)commands

[thaJeztah]

• similar to https://github.com/docker/cli/pull/5233

cli: improve output and consistency for unknown (sub)commands

Before this patch, output for invalid top-level and sub-commands differed. For top-level commands, the CLI would print an error-message and a suggestion to use --help. For missing subcommands, we would hit a different code-path, and different output, which includes full "usage" / "help" output.

While it is a common convention to show usage output, and may have been a nice gesture when docker was still young and only had a few commands and options ("you did something wrong; here's an overview of what you can use"), that's no longer the case, and many commands have a very long output.

The result of this is that the error message, which is the relevant information in this case - "You mis-typed something" - is lost in the output, and hard to find (sometimes even requiring scrolling back).

The output is also confusing, because it looks like something ran successfully (most of the output is not about the error!).

Even further; the suggested resolution (try --help to see the correct options) is rather redundant, because running teh command with --help produces exactly the same output as was just showh, baring the error message. As a fun fact, due to the usage output being printed, the output even contains not one, but two "call to actions";

• See 'docker volume --help'. (under the erro message)
• Run 'docker volume COMMAND --help' for more information on a command. (under the usage output)

In short; the output is too verbose, confusing, and doesn't provide a good UX. Let's reduce the output produced so that the focus is on the important information.

This patch:

• Changes the usage to the short-usage.
• Changes the error-message to mention the full command instead of only the command after docker (so docker no-such-command instead of no-such-command).
• Prefixes the error message with the binary / root-command name (usually docker:); this is something we can still decide on, but it's a pattern we already use in some places. The motivation for this is that docker commands can often produce output that's a combination of output from the CLI itself, output from the daemon, and even output from the container. The docker: prefix helps to distinguish where the message originated from (the docker CLI in this case).
• Adds an empty line between the error-message and the "call to action" (Run 'docker volume --help'... in the example below). This helps separating the error message ("unkown flag") from the call-to-action.

Before this patch:

Unknown top-level command:

docker nosuchcommand foo
docker: 'nosuchcommand' is not a docker command.
See 'docker --help'

Unknown sub-command:

docker volume nosuchcommand foo

Usage:  docker volume COMMAND

Manage volumes

Commands:
  create      Create a volume
  inspect     Display detailed information on one or more volumes
  ls          List volumes
  prune       Remove unused local volumes
  rm          Remove one or more volumes
  update      Update a volume (cluster volumes only)

Run 'docker volume COMMAND --help' for more information on a command.

After this patch:

Unknown top-level command:

docker nosuchcommand foo
docker: unknown command: docker nosuchcommand

Run 'docker --help' for more information

Unknown sub-command:

docker volume nosuchcommand foo
docker: unknown command: 'docker volume nosuchcommand'

Usage:  docker volume COMMAND

Run 'docker volume --help' for more information

cli: improve argument validation output

Improve the output for these validation errors:

• Removes the short command description from the output. This information does not provide much useful help, and distracts from the error message.
• Reduces punctuation, and
• Prefixes the error message with the binary / root-command name (usually docker:) to be consistent with other similar errors.
• Adds an empty line between the error-message and the "call to action" (Run 'docker volume --help'... in the example below). This helps separating the error message and "usage" from the call-to-action.

Before this patch:

$ docker volume ls one two three
"docker volume ls" accepts no arguments.
See 'docker volume ls --help'.

Usage:  docker volume ls [OPTIONS]

List volumes

$ docker volume create one two three
"docker volume create" requires at most 1 argument.
See 'docker volume create --help'.

Usage:  docker volume create [OPTIONS] [VOLUME]

Create a volume

With this patch:

$ docker volume ls one two three
docker: 'docker volume ls' accepts no arguments

Usage:  docker volume ls [OPTIONS]

Run 'docker volume ls --help' for more information

$ docker voludocker volume create one two three
docker: 'docker volume create' requires at most 1 argument

Usage:  docker volume create [OPTIONS] [VOLUME]

SRun 'docker volume create --help' for more information

- Description for the changelog

- improve output and consistency for unknown (sub)commands
- improve output for invalid arguments

- A picture of a cute animal (not mandatory but encouraged)

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 61.90476% with 8 lines in your changes missing coverage. Please review.

Project coverage is 61.46%. Comparing base (5aae44b) to head (c60b360).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #5234 +/- ## ========================================== - Coverage 61.48% 61.46% -0.03% ========================================== Files 298 298 Lines 20813 20816 +3 ========================================== - Hits 12797 12794 -3 - Misses 7104 7110 +6 Partials 912 912 ```