* Move all rust crates (except lib) into crates dir, w/o nesting
* Remove stale path from .gitattributes
* Rename lib.rs files for easier navigation
* Rename mod.rs file for easier navigation
* Fix emscripten-version path
* Fix fixtures dir paths
* Use the default rustfmt settings
* Don't use nightly on CI
- Simplify some workflow steps and auxiliary scripts
- Build library using cmake when not cross-compiling
- Try to fetch fixtures from cache first
- Use `actions-rust-lang/setup-rust-toolchain`
Problem: A failing lint will block running actual tests, adding friction to contributors who will have to golf the linter before getting to see actually useful test results.
Solution: Don't gate `sanitize` and `build` behind successful `checks` so you can see whether your code works at all _before_ worrying about its quality. (In general, the more feedback you get at the same time, the fewer edit->push->test cycles you need, _saving_ CI time in the long run. Only skip tests you are sure to be useless given previous failures.)
Switch the release trigger from PR to a git tag. In practice this would
mean tagging a commit in master branch and pushing it with
`git push --tags`.
The benefit of this is that tagging is already an event that is reserved
for maintainers, so we can remove the need for verifying whether the
event was done by a maintainer.
We also no longer need to keep track of the tag. Previously the trigger
was a PR which has a different ref from the tag, so manual bookkeeping
was required to ensure github used the tag reference instead of the PR
reference. Having the tagging itself be the trigger removes this need
entirely as the default checkout will already use the tag as reference.
