Use npm to manage tool dependencies

[per1234]

This is a sync of a change made in the upstream assets, validated there and already in use in other Arduino Tooling projects: arduino/tooling-project-assets#240

Some of the project infrastructure use tools sourced from the npm software registry.

Previously, the version of the tools used was not controlled. This was problematic because:

• A different version of the tool may be used on the contributor's machine than on the CI runner, resulting in confusing failures.
• The project is immediately subject to disruption or breakage resulting from a release of the tool.

An example of the latter is seen here, where a new release of a transitive dependency cause spurious failure of the "Check Markdown" workflow:

https://github.com/arduino/serial-monitor/runs/8159584293?check_suite_focus=true

---

These tools were installed via either of the following methods:

npx <pkg>

This approach has the following behaviors of interest:

https://docs.npmjs.com/cli/v8/commands/npx#description

If any requested packages are not present in the local project dependencies, then they are installed to a folder in the npm cache, which is added to the PATH environment variable in the executed process.

Package names provided without a specifier will be matched with whatever version exists in the local project. Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency.

This means that the version used was:

1. Whatever happens to be present in the local npm cache
2. The latest available version if it is not already present

npm install --global <pkg>

The latest available version of the package is used.

---

The new approach is to specify the version of the tools via the standard npm metadata files (package.json + package-lock.json). This approach was chosen over the npx <pkg>@<version> alternative for the following reasons:

• Enables automated updates via Dependabot PRs
• Enables automated vulnerability alerts
• Separates dependency management from the asset contents (i.e., no need to mess with the taskfile or GitHub Actions workflow on every update)
• Matches how we are already managing Python dependencies (pyproject.toml + poetry.lock)