Implement system to handle varying platform module names/compatibility across platforms

[AndrewKahr]

This serves as an alternative to #150 and game-ci/versioning-backend#39. It adds an additional internal github action to handle issues caused by varying module names and compatibility being added for additional target platforms by Unity. It can mark target platforms as incompatible so the system skips building it, for example, GameCI doesn't provide Android on linux below 2019.3 so the action is set such that Android is incompatible on Linux for any version below 2019.3. This also handles modules being renamed over time. For example, uwp-il2cpp became universal-windows-platform in 2019. The action has a mapping defined such that it knows when universal-windows-platform is requested, and the version of unity is below 2019, it will return the correct module name of uwp-il2cpp for the docker build while it remains universal-windows-platform in GameCI labels to reduce complexity in Unity-Builder. Since there is no clean divide between legacy and postX versions, there would need to be work done in versioning-backend every time we needed a new workflow, and more complexity added when windows and linux compatibility diverge. Having this compatibility action should make it easier to handle new modules being added in later versions without needing to make adjustments to the versioning-backend. Unlike #150 and game-ci/versioning-backend#39, this requires no changes on the versioning-backend for functionality.

Changes

• Add new internal GitHub Action module-compatibility-handler
• Make windows editor workflows check the module-compatibility-handler for module naming and whether a specific module is compatible. (The action is also compatible with Linux, we can add support into the workflows later if deemed necessary)
• Build il2cpp for all versions (This was mistakenly disabled for legacy versions)
• Ported report-to-backend to typescript and stopped tracking node modules

Checklist

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

---

Copilot summary

This pull request introduces a new GitHub Action named "Module Compatibility Handler" and includes several configuration and source code changes to support it. The most important changes include adding configuration files for code formatting and linting, defining the action's behavior, and implementing the core logic for module compatibility checks.

Configuration and Setup:

• .github/workflows/actions/module-compatibility-handler/.editorconfig: Added configuration for consistent code formatting.
• .github/workflows/actions/module-compatibility-handler/.eslintignore: Added ignore rules for ESLint.
• .github/workflows/actions/module-compatibility-handler/.eslintrc.json: Added ESLint configuration with plugins and rules.
• .github/workflows/actions/module-compatibility-handler/.prettierignore: Added ignore rules for Prettier.
• .github/workflows/actions/module-compatibility-handler/.prettierrc.json: Added Prettier configuration for code formatting.

Core Logic Implementation:

• .github/workflows/actions/module-compatibility-handler/src/check-module-compatibility.ts: Implemented functions to check module compatibility for Windows, Linux, and Mac platforms.
• .github/workflows/actions/module-compatibility-handler/src/compare-unity-versions.ts: Added a utility function to compare Unity versions.
• .github/workflows/actions/module-compatibility-handler/src/index.ts: Defined the main action logic to validate module compatibility based on platform and set outputs accordingly.
• .github/workflows/actions/module-compatibility-handler/src/module-handler.ts: Implemented functions to fetch available modules and filter out incompatible ones.
• .github/workflows/actions/module-compatibility-handler/src/two-way-map.ts: Added a TwoWayMap class to handle module name mappings.

[github-actions[bot]]