Introduce CLI / Introduce Deno

[webbertakken]

Changes

• Rewrite relative imports to use .ts and not reference folders
• Handle env variables process.env becomes Deno.env.get()/set()
• Handle process.platform and other usages of node process.
• Convert __dirname and __filename to use Deno replacement
• Convert Node package AWS SDK to use Deno replacement
• Test AWS flow
• Convert Node package K8s SDK to use Deno replacement
• Test K8s flow
• Convert Node package crypto to use Deno replacement
• Convert Node package path to use Deno replacement
• Convert Node package fs (sync) to use Deno replacement
• Convert Node package fs/promises (async) to use Deno replacement
• Convert Node package @actions/core to use Deno replacement
• Convert Node package @actions/exec to use Deno replacement
• Convert Node package semver to use Deno replacement
• Convert Node package nanoid to use Deno replacement
• Convert Node package commander-ts to use Deno replacement
• Convert Node package uuid to use Deno replacement
• Convert Node package zlib to use Deno replacement
• Convert Node package yaml to use Deno replacement
• Convert Node package console to use Deno replacement
• Convert Node package child_process to use Deno replacement
• Convert Node package unity-changeset to use Deno replacement
• Command deno run -A --unstable src/index.ts not erroring out
• Port async-wait-until which is currently not available on Deno.
• Setting composite action to install deno and run deno run -A --unstable src/index.ts with params (pretty much exactly like this as implemented in Draft: feat: introduce deno cli entrypoint unity-builder#385)
• Make compatible with /dist
• Successful build in CI
• Remove pre-commit build hook that compiles the dist files every time (as we can now run directly from src)
• Determine whether to release as 2.x or 3.x (technically it doesn't have to be a breaking change per se)
• Add checks / tests

High level functionality:

• Load user input
• Run docker
• Build project
• Output files
• Cloud Runner

Milestones:

• Separate logic between game engines
• Separate commands like build, test, remote etc.
• Separate cli input
• Separate env input
• Introduce config folder / input
• Separate defaults
• Use all of the above in an intuitive CLI signature

Next steps after completing this:

• Start writing CLI from Unity Builder logic in Create CLI #4 as per v3.0.0 roadmap
• Move CLI to its own repository and base unity-builder on that CLI
• base all other actions on that CLI
• base all other CI systems on that CLI as well

Checklist

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

[github-actions]