Some tasks accept input via environment variables. It is important to document these parameter variables.
Previously, the parameter environment variables of these tasks were undocumented.
Typically, the documentation is done in the task description, to make the information easily accessible to contributors
via the `task list` output. However, this approach was intentionally eschewed in the case of the `yaml:lint` task, where
the documentation was instead placed in a comment. The reason is that this task's parameter variable is only useful when
the task is executed by a GitHub Actions workflow, as is done already in the "Check YAML" workflow. So the contributor
running the task from the command line has no need for this information and thus including it in the description would
only clutter up the `task list` output with content useless to the reader of that output.

Tasks are provided to perform common project development and maintenance operations. Some of these tasks are configured
by setting an environment variable from the invocation. It will be important for the contributor to be aware of these
variables when using the task directly (as opposed to via the "umbrella" convenience functions which set the variables
as appropriate for the project).
Previously, when done at all, the variables where documented in comments in the taskfile. The contributor would only see
that information if they looked at the source content of the taskfile, but a contributor would only be expected to do
that if they were working on the taskfile source. The documented way for a contributor to learn about the available
tasks is by running the `task --list` command. This displays the contents of the task's `desc` field. So the parameter
variables must be documented in that field.

Some tasks accept input via environment variables. These parameter variables are documented in the task description.
A standard format has been established for that documentation. Previously, these descriptions did not follow the
standardized format.
Typically, the documentation is done in the task description, to make the information easily accessible to contributors
via the `task list` output. However, a description was intentionally omitted for these tasks. The reason is these tasks
are for internal use by other tasks, only serving to avoid code duplication. So the tasks should not be listed in the
`task list` output. Task actually has a feature for marking such tasks as internal, but unfortunately that only works
for the standard way of calling a task from another task, which can not be used in this case where the output of the
task must be captured. For this reason, the task documentation is intentionally done via a comment instead of the
description as would be done for a contributor facing task.