RFC: allow adding more data to YAML frontmatter - syntax and proposed fields

## Short Description

As described in #5099 and #4954 I think that the YAML frontmatter in the `.RULE` and `.LICENSE` fields should be made more extensible to capture more information, that makes it easier to trace information across various sources, link to discussions inside the issue tracker, and so on.

Although I can envision several useful additions, there are probably many more that I didn't envision, so I am proposing two kinds of fields:

* standardized fields, officially supported by scancode
* local extension fields, not officially supported by scancode (but could be in the future)

## Possible Labels

- new feature

## Select Category

- [X] Enhancement
- [ ] Add License/Copyright
- [ ] Scan Feature
- [ ] Packaging
- [ ] Documentation
- [ ] Expand Support
- [ ] Other

## **Describe the Update**

I am proposing to add extra fields to the YAML frontmatter and plan for the future by adding local extension fields.

Extension fields should be prefixed with `x-` (similar as to local e-mail headers) are not (necessarily) supported in Dejacode (or other official tools), while officially supported fields are just plain, are supported in Dejacode (or other official tools.

Currently I am envisioning the following fields:

* `aboutcode-issue`: explained in #5099. Basically: whenever a new license rule or license file is added to the licensedb add a pointer to the issue tracker, because the issue can contain important discussions about the license, that would otherwise be invisible without digging through Git logs and manual searches
* `spdx-list`: explained in #4961. Whenever a license from SPDX is added to the licensedb it isn't clear from which version of the SPDX license list it is (as data there could also potentially change). By adding the version number of the list that it corresponds to to the license file itself it is immediately clear. Currently the SPDX version list is only present when actively scanning with scancode.
* `test_file` (or `test_files`): explained in #4953 and primarily for rules. I am missing references to test files so it sometimes is a mystery where rules are coming from. There is some information in some `notes` sections but those aren't very consistent.
* `huggingface`: explained in #4954. Huggingface is a huge source of new licenses and they use a different naming schema. I coudld also envision this being an extension, so `x-huggingface`

## **How This Feature will help you/your organization**

It adds a lot of metadata, or at least references to metadata that is currently hard to find.

## **Possible Solution/Implementation Details**

## **Example/Links if Any**

## **Can you help with this Feature**