refactor(aria_metadata): generate ARIA metadata from specification

[Conaclos]

Summary

Our ARIA metadata are currently handwritten and mostly based on ARIA 1.1 (some of them are in ARIA 1.2).
Some of these metadata are erroneous or incomplete.
I first started to update them manually. However, this took too much time and it is error-prone.

The aria-query NPM package provides a JSON file with the ARIA metadata.
This seems to be manually updated.
I also noticed several issues and some lack of fidelity with the specification (they mix related and base concepts for example).

Thus, I decided to write a script that extracts ARIA metadata directly from the specification.
The script is written in JavaScript and relies on happy-dom NPM package that parse the HTML page of the ARIA specification.
I chose happy-dom because it has less dependencies than jsdom and linkedom. It is also more used than linkedom.
This is a best effort approach, however the generated data seems pretty good (I tried for the three available versions of ARIA).
I placed the script in packages/aria-data.

I updated the biome_aria_metadata build.rs script to generate its code from aria-data.json.
For now, aria-data.json is symlinked to packages/aria-data/aria-data-1-2.json.
I used the prettyplease crate (widely used in the community) to format the output of build.rs.
I think it is a better alternative to starting a process to run rustfmt.

Now that we have a pretty reliable ARIA metadata source, we will be able to transfer more stuff from biome_aria to biome_aria_metadata.

Test Plan

CI must pass.

[github-actions]

Parser conformance results on

js/262

Test result	main count	This PR count	Difference
Total	48515	48515	0
Passed	47324	47324	0
Failed	1191	1191	0
Panics	0	0	0
Coverage	97.55%	97.55%	0.00%

jsx/babel

Test result	main count	This PR count	Difference
Total	40	40	0
Passed	37	37	0
Failed	3	3	0
Panics	0	0	0
Coverage	92.50%	92.50%	0.00%

symbols/microsoft

Test result	main count	This PR count	Difference
Total	6570	6570	0
Passed	2203	2203	0
Failed	4367	4367	0
Panics	0	0	0
Coverage	33.53%	33.53%	0.00%

ts/babel

Test result	main count	This PR count	Difference
Total	680	680	0
Passed	608	608	0
Failed	72	72	0
Panics	0	0	0
Coverage	89.41%	89.41%	0.00%

ts/microsoft

Test result	main count	This PR count	Difference
Total	18431	18431	0
Passed	14114	14114	0
Failed	4317	4317	0
Panics	0	0	0
Coverage	76.58%	76.58%	0.00%

[codspeed-hq]

CodSpeed Performance Report

Merging #4055 will improve performances by 6.28%

_{Comparing conaclos/aria-data (1b975f4) with main (a3483e4)}

Summary

⚡ 1 improvements
✅ 106 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	conaclos/aria-data	Change
⚡	db_17847247775464589309.json[cached]	13.9 ms	13.1 ms	+6.28%

[Conaclos]

@ematipico I chose happy-dom because it has less dependency than linkedom and has more NPM downloads. Thanks for the suggestion!

[DaniGuardiola]

A DOM library like happy-dom or jsdom is perfectly fine and gets the job done, but just wanted to make a note that for most scraping needs of mostly static content you don't really need a DOM, and you can get by with a simple XML/HTML parser like cheerio. This is normally at least some orders of magnitude faster, and there are some tools that simplify this further with a scraping-focused API like surgeon.

All of this said, if this is something that just needs to run manually every once in a while, a DOM library is perfectly fine. However, if there are plans to run this frequently (e.g. in CI for every PR), then I'd strongly suggest switching to a parser approach.

[ematipico]

We will rarely run this job, considering that it's computed from source.

[Conaclos]

@DaniGuardiola

Thanks for the pointers.
Indeed, cheerio could be a better option.
I decided to keep happy-dom because it is good enough and as you said it is rarely run.
The script is there for reproducibility and to be able to extract data once ARIA 1.3 is stable.