Split compiletests and difftests into parallel CI jobs

[LegNeato]

We could have them kick off after the main job and reuse artifacts, but it seems better to just kick them all off at once?

[LegNeato]

End-to-end CI Times:

• Before difftests: ~27 mins
• After difftests: ~38 mins
• This PR: ~21 mins

[Firestar99]

I'd only make them depend on each other if we run out of ci runtime tokens, but they're free for open source projects so... who cares.

I've added two more things:

• separated the android build out into it's own thing
• check the lockfile in difftests for uncommitted changes

[Firestar99]

baseline: ~22 min

Most of our CI is now below 10min, apart from the main test. The slowest component is the workspace test with 7m on ubuntu/mac and 10m on windows. I think most of that is coming from release compiling our examples, which depend on ash, wgpu and winit, so I excluded them from testing. They don't have any tests anyway, so the following check on examples should be sufficient.
-> ~23 min regression?, reverting for now

Also it doesn't have "use-installed-tools"!
-> ~19 min, linux & windows: -3min, mac: -7min

We also need to exclude our new difftests, as they too depend on wgpu. I moved their testing to our difftest ci and readded the examples exclusion.
-> ~16 min min

windows test is the slowest with 16min, followed closely by windows difftest with 15min. Comparing to ubuntu and mac:

• cargo fetch takes 1min, whereas it takes <7s on unix
• build example shaders (in release) seems to be a clean build on windows with 2m30, where it's an incremental on unix with ~30s
• running the difftest does not reuse artifacts from difftest/lib due to being run in a different workspace
• in general windows is 1.5-2x slower in building rust, but that's expected

[Firestar99]

I'm giving you the 👍 but disabled auto-merging so you can have another look at my changes

[LegNeato]

I'm fine with the changes, though I think it is cleaner to split by "type" (unit, diff, compile) rather than by crate (e.g. the difftest job running difftest and their associated unit tests).

But this isn't too complicated yet so it doesn't really matter either way.