v5 rework #47

V4 has a number of problems.

• The patcher matrix is large. large enough that builds take a very long time!
• Each entry added to the matrix adds megabytes to the nupkg's size
• NetCode V2 has a lot of new conditional compilation symbols based on what packages are installed in the project.
  • This would necessitate expanding the already large matrix.
• There is file overlap between the patchers, causing problems when patching a different Unity version.

This list is not exhaustive.

To try to resolve these, we make a few assumptions/restrictions:

• All users of netcode patcher have a dotnet SDK available, i.e. we can do csharp compilation on their machine.
• Most users of netcode patcher have a git client available.

v5 should be fundamentally different from v4.

• Patchers could be compiled by users at build-time.
• Or, a very restricted set of patcher 'presets' could be bundled.
  • This set would need to be updated each time a game updates.
  • Could we host these somewhere, e.g. NuGet, GitHub?
    • GitHub release assets would do the trick
    • could use Actions artefacts, but that is more hacky + not persistent
    • Could use GitHub nuget registry
      • would necessitate setting up something to auth. with the registry
• To build a patcher, the following must be known:
  • The targeted Unity version (some Editor assemblies are required)
  • Versions of all (relevant) Unity packages in the project, especially of NetCode
  • Whether native collection support was enabled.

Outstanding questions:

• Can we cache built patchers? what input(s) should influence the cache key?
• How should required Editor assemblies be supplied?
  • 'BYO' editor assemblies could be helpful
  • in CI, editor assemblies need to be accessible without running a unity editor action, they are too slow
• How should users provide the required 'spec'?
  • Can we include some spec 'presets' e.g. --preset lethal-company-v81, --preset mycopunk-v1.4 ?