Cache target/ folders in CI

[ErichDonGubler]

TODO: Explain why this is a good idea:

• We will definitely need this for speeding up CI, which is the real
  impetus here.
• This basically shouldn't affect anybody that is using a library
  version of Naga; only binaries consumers, who still have a choice
  whether they will honor a Cargo.lock.

Current stats on savings:

File, job name, optionally step	Total runtime of job (pre-caching)	Total runtime of step (pre-caching)	Time spent compiling stuff with Cargo (pre-caching)	Time spent compiling stuff with Cargo (post-caching)	Cache size
ci.yml:check-msrv	2m 16s	-	1m 43s	1m 0s	139 MB
ci.yml:test:Default test	4m 12s	2m 07s	2m 07s	17s	303 MB
ci.yml:test:Test all features	4m 12s	1m 53s	1m 39s	46s	303 MB
ci.yml:check:Check benchmarks	2m 49s	2m 09s	2m 08s	19s	146 MB
ci.yml:check:Check naga-fuzz	2m 49s	36s	35s	30s	146 MB
ci.yml:documentation	1m 59s	-	1m 55s	25s	127 MB
validate-linux.yml:validate-linux	2m 29s	-	2m 06s

[cwfitzgerald]

Curious: how does this compare to the rust-cache action from matklad?

[ErichDonGubler]

@cwfitzgerald: I don't know what you're referring to. Got a link?

[cwfitzgerald]

Ah sorry, gave you the wrong source :) https://github.com/Swatinem/rust-cache

[ErichDonGubler]

@cwfitzgerald: In fact, that is the tool being used in this PR. 😉

[cwfitzgerald]

Hello, thank you for your PR against Naga!

As part of gfx-rs/wgpu#4231, we have moved development of Naga into the wgpu repository in the Naga subfolder. We have transferred all issues, but we are unable to automatically transfer PRs.

As such, please recreate your PR against the wgpu repository. We apologize for the inconvenience this causes, but will make contributing to both projects more streamlined going forward.

We are leaving PRs open, but once they are transferred, please close the original Naga PR.