While working on#4952 I split the linting job into multiple jobs.
I figured that we can do the same for all parts of our CI. With each step being its own job it means:

• Each will be independently shown in the signals box. This means if one fails, it's immediately obviouswhich job failed without digging into logs.
  • This is useful on mobile where the GH app pushes you into the mobile browser to view action details.
• One failure doesn't fail everything else - allowing you to see all passes/fails regardless of a single failure.
  • E.g. bad spelling shouldn't block the format checker, and one package's test shouldn't block another's.
• All jobs are run in parallel on separate machines - automatically by GH.
  • This should save us a lot of time in the testing (hopefully around 6 mins).
  • This also means that you can see the results of smaller jobs earlier, without waiting for slower steps to finish.
    • E.g. format check is fast (~1m total), but linting is slow (~4m) - and seeing that signal earlier is nice.
• We can block the build earlier by creating a hierarchy of jobs.
  • Right now if yarn is having issues then all jobs fail at once. Or sometimessome jobs might fail whilst others don't. Separating the install + cache into its own step will mean just the install job fails clearly and blocks everything. Similarly if there's a build failure - all jobs will fail.

This PR actions the above to create a workflow for our CI:

1. Run the install and cache the install artefacts
   • This is the same as before, however now we do it as its own job so it's guaranteed to be done exactly once - there's no race condition where 2 jobs might do the install if they both run before the cache is filled.
2. Build and (basic) Lint in Parallel
   a) Run the build and cache the output
   b) In parallel we also any steps that don't need the build:
   a) Prettier
   b) Markdownlint
   c) Spellcheck
3. Run the build-dependent steps in parallel
   a) ESLint
   b) Typecheck
   c) Integration tests
   d) Website tests
   e) Unit tests for all packages on different node versions (each package / version is run as a separate job)
4. Upload codecov results, collected from the main node version tests only.

I also:

• moved the preparation steps into reusable actions so they're not copy+pasted everywhere
• ran all of the unit tests using a matrix instead of in a monolithic job. this means we get one signal per package per node version (applying all the above justifications to our tests)

Comparison:

Before:

After: