The uses of these was eliminated in the updates to the formatting and documentation infrastructure, but I forgot to
remove them from the taskfile at that time.

There is an established practice of providing the developer with convenience tasks which collect all the domain-specific
tasks of a given class. This has a couple of benefits:
- Provides an alternative to manually running multiple tasks
- Provides a standardized interface to the project, independent from its unique underlying details
However, I have come to the conclusion that these benefits lessen as the number of such convenience tasks increases. At
the same time, the maintenance burden increases. In the end, I think there are only three distinct classes of tasks that
can be consolidated in this manner:
- "build" (build the application)
- "check" (check for problems with the project)
- "fix" (automatically fix problems with the project)

I originally set out to establish some logical order to the tasks, based partly on the Arduino CLI taskfile, as that
project was used as a model, then on some indecipherable criteria of my own devizing in cases where the model did not
provide guidance. In the end, it resulted in a jumble.
Alphabetical order is completely objective and it results in a fairly logical order in the end due to the the use of
prefixes on the task names according to their domain. The exception is that the convenience "umbrella" tasks have been
left at the top (in their own alphabetical order) so that they will have the maximum visibility as the most useful tasks.
Even that is not completely inconsistent, since these don't have a namespace prefix, and so might be imagined to have a
null global namespace prefix that would be sorted first.