New experimental method to avoid duplicate editor workflows

[AndrewKahr]

We have a major issue of duplicate workflows and more complicated logic as Unity continues to add/remove modules for different versions of the Editor. To fix this I've implemented a method of scraping supported modules for a specific version of Unity, filter against a compatibility filter to remove modules that we don't support, and pass that to the requested build so it knows what to build. See game-ci/docker#150 for details on the docker workflow implementation.

Requires game-ci/docker#150

Changes

• Implement scraper for supported editor modules
• Implement filtering system to remove modules we don't support
• Separate event triggers for windows and linux based builds so modules can be granularly filtered
• bump to es2020 for string.matchAll
• add missing modules to dependencies
• adds cross-fetch to make fetch requests to the unity API endpoint

Checklist

• [x] Read the contribution guide and accept the code of conduct
• [x] Readme (updated or not needed)
• [x] Tests (added, updated or not needed)

[webbertakken]

I agree that ultimately this would be the way to go (given some changes, reducing complexity and with well defined separation of responsibility and forks should keep being able to use the workflows in docker repo as standalone using workflow_dispatch)

Unfortunately I currently do not have capacity to debug more large changes to our build flow. As introducing and synchronising workflow changes between this repository and versioning backend usually requires a good amount of debugging, which happens to be very tedious work while on the clock of the scheduler which runs every 15 minutes.

We also need to first stabilise builds that are currently failing https://game.ci/docs/docker/versions. v0.15 was the last version where all builds were working as expected.

In the meantime, a simpler way to achieve this would be to follow the existing approach for differentiating between target platforms for different versions (i.e. legacy, post_x, post_y,post_z`) and simply have another workflow describes which target platforms to use for that version.

Note that you can diff between the workflows in WebStorm using Compare with clipboard, and you'll see that there are only 2 lines different, which make the complexity very manageable currently.