Spell-checking should allow reusable configuration files (OSOE-579)

[BenedekFarkas]

Check-spelling has a built-in feature to be able use external dictionary files that we utilize that through the additional-configuration-source-prefixes and additional-dictionaries parameters.

Lombiq/Open-Source-Orchard-Core-Extensions#346 adds custom functionality on top of that to allow copying advice.md from LGHA if it doesn't exist in the workspace, as well as merging some of LGHA's configuration files (excludes.txt, line_forbidden.patterns and patterns.txt) into the ones found in the workspace. However, for proper opt-in configuration, these files are each copied/merged in separate steps with fairly similar logic. This is necessary, because check-spelling doesn't allow referencing every type of configuration file, only flat dictionary files.

Let's fix that by generalizing the logic and make the rest of the configuration files reusable like flat dictionary files. This can be achieved by using already existing prefix parameter(s), but entries in the list of files need to include the type of the configuration file, e.g., instead of 'prefix':'relative-path' (like for dictionary files), use the 'type':'prefix':'relative-path' format. type can be one of predefined values that identify the type of configuration file, such as excludes, patterns, etc. An example of using configuration files from LGHA would look like this:

default-configuration-files:
  description: Space delimited list of configuration files in the 'type':'prefix':'relative-path' format.
  required: false
  default: |
    excludes:lombiq-lgha:excludes.txt
    patterns:lombiq-lgha:patterns.txt

and/or

with:
  additional-configuration-source-prefixes: >
    {
      "other-project": "https://raw.githubusercontent.com/Other/Project/dev/.github/actions/spelling/",
    }
  additional-configuration-files: |
    excludes:other-project:excludes.txt
    patterns:other-project:patterns/simple-patterns.txt
    patterns:other-project:patterns/complex-patterns.txt

When processing such configuration file entries, the following steps are needed ("type" refers to the type of the configuration file currently processed):

1. Create the "type" folder in the workspace configuration folder, if it doesn't exist.
2. If the "type" file exists in the configuration folder, move it to the "type" folder.
3. Download the referenced file to the "type" folder with its name updated to: <original-name>-<url-prefix>-<new-guid>.
   • "url-prefix" is added to be able to identify where the file came from.
   • "new-guid" is added to avoid file name collisions.
4. If the file is not found, throw an error and halt the process.

Jira issue