Consolidate convenience "umbrella" tasks

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)

Author: per1234

Taskfile.yml

@@ -35,11 +35,17 @@ tasks:
     deps:
       - task: go:build
 
-  test:
-    desc: Run tests
-    cmds:
-      - task: go:test
-      - task: go:test-integration
+  fix:
+    desc: Make automated corrections to the project's files
+    deps:
+      - task: general:format-prettier
+      - task: general:correct-spelling
+      - task: go:generate
+      - task: go:fix
+      - task: go:format
+      - task: markdown:fix
+      - task: python:format
+      - task: shell:format
 
   # Source: https://github.com/arduino/tooling-project-assets/blob/main/workflow-templates/assets/go-task/Taskfile.yml
   go:build:
@@ -80,43 +86,21 @@ tasks:
       - poetry run pytest tests
 
   check:
-    desc: Lint and check formatting of all files
+    desc: Check for problems with the project
     cmds:
-      - task: go:check
-      - task: python:check
-      - task: docs:check
-      - task: config:check
+      - task: ci:validate
       - task: general:check-formatting
       - task: general:check-spelling
-      - task: shell:check-mode
-
-  lint:
-    desc: Lint all files
-    cmds:
+      - task: go:test
+      - task: go:test-integration
       - task: go:vet
       - task: go:lint
+      - task: markdown:lint
+      - task: markdown:check-links
       - task: python:lint
-      - task: docs:lint
-      - task: config:lint
-
-  check-formatting:
-    desc: Check formatting of all files
-    cmds:
-      - task: general:check-formatting
-
-  format:
-    desc: Format all files
-    cmds:
-      - task: go:format
-      - task: python:format
-      - task: general:format-prettier
-
-  # Source: https://github.com/arduino/tooling-project-assets/blob/main/workflow-templates/assets/check-go-task/Taskfile.yml
-  go:check:
-    desc: Check for problems with Go code
-    deps:
-      - task: go:vet
-      - task: go:lint
+      - task: shell:check
+      - task: shell:check-mode
+      - task: website:check
 
   # Source: https://github.com/arduino/tooling-project-assets/blob/main/workflow-templates/assets/check-go-task/Taskfile.yml
   go:vet:
@@ -269,13 +253,6 @@ tasks:
     cmds:
       - poetry run mkdocs serve
 
-  docs:check:
-    desc: Lint and check formatting of documentation files
-    cmds:
-      - task: markdown:lint
-      - task: markdown:fix
-      - task: markdown:check-links
-
   # Source: https://github.com/arduino/tooling-project-assets/blob/main/workflow-templates/assets/check-shell-task/Taskfile.yml
   shell:check:
     desc: Check for problems with shell scripts
@@ -344,16 +321,6 @@ tasks:
         )"
         exit $EXIT_STATUS
 
-  config:check:
-    desc: Lint and check formatting of configuration files
-    cmds:
-      - task: config:lint
-
-  config:lint:
-    desc: Lint configuration files
-    cmds:
-      - task: workflow:validate
-
   # Source: https://github.com/arduino/tooling-project-assets/blob/main/workflow-templates/assets/check-workflows-task/Taskfile.yml
   ci:validate:
     desc: Validate GitHub Actions workflows against their JSON schema

docs/CONTRIBUTING.md

@@ -95,24 +95,18 @@ task build
 The project uses Go modules, so dependencies will be downloaded automatically. At the end of the build, you should find
 the `arduino-lint` executable in the same folder.
 
-### Running the tests
+<a id="running-the-tests"></a>
 
-There are several checks and test suites in place to ensure the code works as expected and is written in a way that's
-consistent across the whole codebase. To avoid pushing changes that will cause the CI system to fail, you can run most
-of the tests locally.
+### Running the checks
 
-To ensure code style is consistent, run:
+There are several checks and test suites in place to ensure the code works as expected and is written in a way that's
+consistent across the whole codebase. To avoid pushing changes that will cause the CI system to fail, you can run the
+checks locally by running this command:
 
 ```
 task check
 ```
 
-To run all tests:
-
-```
-task test
-```
-
 #### Go unit tests
 
 To run only the Go unit tests, run:
@@ -173,49 +167,17 @@ pytest test_lib.py
 pytest test_lib.py::test_list
 ```
 
-#### Linting and formatting
-
-When editing any Python file in the project, remember to run linting checks with:
-
-```
-task python:check
-```
+<a id="linting-and-formatting"></a> <a id="configuration-files-formatting"></a> <a id="documentation-formatting"></a>
 
-This will run [`flake8`](https://flake8.pycqa.org/) automatically and return any error in the code formatting.
+### Automated corrections
 
-In case of linting errors you should be able to solve most of them by automatically formatting with:
+Tools are provided to automatically bring the project into compliance with some required checks. Run them all with this
+command:
 
-```shell
-task python:format
 ```
-
-#### Configuration files formatting
-
-We use [Prettier](https://prettier.io/) to automatically format all YAML files in the project. Keeping and enforcing a
-formatting standard helps everyone make small PRs and avoids the introduction of formatting changes made by unconfigured
-editors.
-
-There are several ways to run Prettier. If you're using Visual Studio Code you can easily use the
-[`prettier-vscode` extension](https://github.com/prettier/prettier-vscode) to automatically format as you write.
-
-Otherwise you can use the following tasks. To do so you'll need to install `npm` if not already installed. Check the
-[official documentation](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) to learn how to install
-`npm` for your platform.
-
-To check if the files are correctly formatted run:
-
-```shell
-task config:check
+task fix
 ```
 
-If the output tells you that some files are not formatted correctly run:
-
-```shell
-task config:format
-```
-
-Checks are automatically run on every pull request to verify that configuration files are correctly formatted.
-
 ### Working on documentation
 
 Documentation is provided to final users in form of static HTML content generated from a tool called
@@ -238,33 +200,6 @@ task website:serve
 The documentation will build. If you don't see any error, open `http://127.0.0.1:8000` in your browser to local the
 local copy of the documentation.
 
-#### Documentation formatting
-
-We use [Prettier](https://prettier.io/) to automatically format all Markdown files in the project. Keeping and enforcing
-a formatting standard helps everyone make small PRs and avoids the introduction of formatting changes made by
-misconfigured editors.
-
-There are several ways to run Prettier. If you're using Visual Studio Code you can easily use the
-[`prettier-vscode` extension](https://github.com/prettier/prettier-vscode) to automatically format as you write.
-
-Otherwise you can use the following tasks. To do so you'll need to install `npm` if not already installed. Check the
-[official documentation](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) to learn how to install
-`npm` for your platform.
-
-To check if the files are correctly formatted run:
-
-```shell
-task website:check
-```
-
-If the output tells you that some files are not formatted correctly run:
-
-```shell
-task docs:format
-```
-
-Checks are automatically run on every pull request to verify that documentation is correctly formatted.
-
 #### Documentation publishing
 
 The Arduino Lint git repository has a special branch called `gh-pages` that contains the generated HTML code for the