* "Canonical App Name" becomes "Simplified App Name"
* devscript `cask_namer` renamed to `generate_cask_token`
* doc file `CASK_NAMING_REFERENCE.md` renamed to `cask_token_reference.md`
* DSL uses `"#{token}"` for interpolation instead of `"#{title}"`
* documentation text
* backend code (variables, method, class names)
* error message text
* tests
* code comments
* Cask comments
* emphasize `tags :name`
* doc: use "vendor" consistently instead of "developer"
* doc: many man page argument descriptions were incorrect
* incidental clarifications
Many backend variables similar to `cask_name` or `cask` have
been standardized to `cask_token`, `token`, etc, resolving a long-
standing ambiguity in which variables named `cask` might contain
a Cask instance or a string token.
In many places the docs could be shortened from "Cask name" to
simply "token", which is desirable because we use the term "Cask"
in too many contexts.
- Show a more user-friendly error message when dealing with an option whose (mandatory) argument is missing.
- Likewise, we show a more user-friendly error message when a given option is ambiguous. Examples:
- Given `-f`, the parser successfully expands to `--fontdir`.
- Given `-c`, we fail to expand because the parser can’t tell if the user means `--caskroom` or rather `--colorpickerdir`. This exception now results in a nicer error message.
- Some commands now result in a consistent error message when a required cask name is missing.
This affects all stable commands which require one or more cask names as arguments, i. e. `cat`, `create`, `edit`, `fetch`, `info`, `install`, `uninstall`, and `zap`.
- Up to now, the commands `cat`, `create`, `edit`, and `info` used to treat any unknown option as a cask name. This commit changes that behaviour to make it consistent to the rest of the commands (like `fetch`, `install`, `uninstall`, and `zap`), who have silently discarded any unknown option in the past, and continue to do so.
