This update will pick the followin fix in arduino-cli:

arduino/arduino-cli#433

- Allow loading of global user-define platform.txt
(arduino/arduino-cli#469)

- Fixed nil pointer exception on some rare case with
  multiple libs selection
(arduino/arduino-cli#477)

Fix #345

- Auto-disable (deep) caching of core builds if needed
  arduino/arduino-cli#479

- Print "multiple libraries found for header.h" message only when it really happens.
  arduino/arduino-cli#478

Fix library priority selection
- arduino/arduino-cli#565

Load contents of source files only when needed
- arduino/arduino-cli#559

Allow naming sketches like "RCS" and "CVS"
- arduino/arduino-cli#537

See #348 (comment)

- Fix library priority selection (again)
  arduino/arduino-cli#574

- Improve precompiled libraries handling
  arduino/arduino-cli#512

- Reduce priority for IDE-bundled platform releases
  arduino/arduino-cli#579

- Fixed wrong escaping on legacy MachineLogger
  arduino/arduino-cli#577

- Improved build progress reports:
  arduino/arduino-cli#625

- Removed automatic '--relax' hack for compiles on Atmega2560 MCU
  arduino/arduino-cli#749

- Fixed skethbook+bootloader hex merger.
  arduino/arduino-cli#744

- Fixed race condition in legacy i18n.LoggerToCustomStreams
  arduino/arduino-cli#704

- Fixed path-relativization error when traversing different partitions
  arduino/arduino-cli#658

- Add macro during lib discovery phase
  arduino/arduino-cli#633

- legacy: Improved progress report from Compile
  arduino/arduino-cli#625

Imported grpc server from cli legacy

Added Power Support ppc64le

Add security policy link to readme

…compile unsaved sketches

See arduino/arduino-cli#1290

On every push that changes relevant files, and periodically, configure the repository's issue and pull request labels
according to the universal, shared, and local label configuration files.

Add CI workflow to synchronize with shared repository labels

Incorrect context key name resulted in impossible to satisfy conditional, meaning the dry run determination code was
solely dependent on the check for whether the workflow was triggered from the default branch name.

In order to facilitate the testing and review of proposed changes to the repository label infrastructure, the
"Sync Labels" template workflow does a dry run when triggered under conditions that indicate it would not be appropriate
to make real changes to the repository's labels. The changes that would have resulted are printed to the log, but not
actually made.

One of the criteria used to determine "dry run" mode usage is whether the event occurred on the repository's default
branch. A trigger on a development branch or for a pull request should not result in a change to the labels.
It turns out that GitHub does not define a `github.event.repository.default_branch` context item when a workflow is
triggered by a `schedule` event. This resulted in the workflow always running in "dry run" mode on a `schedule` trigger.
Since `schedule` and `repository_dispatch` triggers are only permitted for the default branch, there is no need to check
whether the event's ref matches the default branch and it is safe to always run in write mode on these events.

Fix bugs in dry run determination code for "Sync Labels" workflow

The `carlosperate/download-file-action` action is used in the GitHub Actions workflows as a convenient way to download
external resources.

A major version ref has been added to that repository. It will always point to the latest release of the "1" major
version series. This means it is no longer necessary to do a full pin of the action version in use as before.

Use of the major version ref will cause the workflow to use a stable version of the action, while also benefiting from
ongoing development to the action up until such time as a new major release of an action is made. At that time we would
need to evaluate whether any changes to the workflow are required by the breaking change that triggered the major
release before manually updating the major ref (e.g., uses: `carlosperate/download-file-action@v2`). I think this
approach strikes the right balance between stability and maintainability for these workflows.

Use major version ref of `carlosperate/download-file-action`