This is the template workflow filename, which is intended to serve as a unique identifier, and thus must be a bit more
verbose.

These are the naming conventions established in the standardized template workflow.

This will make version bumps easy, especially as additional jobs are added to the workflow

The paths filter is used to configure whether the workflow should be triggered based on which files were modified. The
workflow should run every time it is modified, so it should be in the paths filter.

Even though not all these paths apply to this specific project, this change is pulled in from a template workflow which
is intended to be applicable to any project containing Python files.

The `workflow_dispatch` event allows triggering the workflow via the GitHub web interface. This makes it easy to trigger
an immediate workflow run after some relevant external change.

The `repository_dispatch` event allows triggering workflows via the GitHub API. This might be useful for triggering an
immediate check in multiple relevant repositories after an external change, or some automated process. Although we don't
have any specific need for this event at the moment, the event has no impact on the workflow, so there is no reason
against having it. It is the sort of thing that can end up being useful if it is already in consistently in place, but
not worth setting up on demand, since the effort to set it up is greater than the effort to trigger all the workflows
manually.

The badges provide a prominent indication of the repository's CI status at a glance. This may help to bring potential
issues to the attention of the maintainers.

"Umbrella" tasks that run multiple related specific tasks can be convenient for the developer (though not so much in this
particular case) by allowing them to avoid typing extra commands.. However, these tasks should not be used in the CI
workflows. The reason is that more granular checks make the workflow result easier to understand in the event of a
failure.

No real functional difference or real advantage to either order, but this is the way it is in the standardized "template"
workflow, so it must be so here as well.

This will cause error messages to be surfaced in the workflow run summary and logs, making it easier to discover the
cause of a workflow run failure.

There is a significant amount of overlap between flake8 and the black Python formatter tool used by this project.
However, flake8 compliance is not a guarantee of black compliance, so it is necessary to add a dedicated formatting
check.

This will show the related source code in the output when there is a rule violation in the repository's Python code.

Poetry is used for managing the project's Python dependencies. This means that several development processes require
first running a dependency installation command. Rather than having that command duplicated across the taskfile, it can
be put in a dedicated task. This also allows it to be run from the task's `deps` key, which allows it to run in parallel
to any other setup processes the task might have.

We have assembled a collection of reusable project assets:
https://github.com/arduino/tooling-project-assets
These will be used in the repositories of all Arduino tooling projects.

This change only provides a sync with the upstream asset and has no functional effect.