Further CI caching improvements (blocked on upstream)

[Radvendii]

Right now there are a couple of slowdowns of CI that we can address once this crane issue is resolved.

• Every build (docs, core, lsp, etc) rebuilds a whole bunch of dependencies (though not all).
  • It triggers for dependencies that have a build.rs
• Every build rebuilds nickel-lang-core.
  • I'm pretty sure the fix for this is to use nickel-lang-core as the craneArtifacts of the other build
  • But currently the above issue will cause it to rebuild it anyways, so there's no way to check that this actually helps.
  • The disadvantage of this is that we sort of end up recreating the internal build graph in flake.nix. In this case the build graph is pretty simple, so maybe it's not a problem.
• Lalrpop is slow, and not changed often.
  • On my machine it takes 1:30.
  • If we made it a separate crate, and make it the craneArtifacts of nickel-lang-core, it would get cached in CI most of the time
  • The same issue as above means that we can't actually check this until that original issue is resolved
• Whenever any file changes, we rebuild all crates in CI.
  • We could fix this with more detailed source filters, but...
  • This would be kind of finicky and
  • Most of the time we're modifying nickel-lang-core, which is a dependency of all the other crates anyways
  • My inclination is to just not do this

[Radvendii]

Rebuilding dependencies addressed by #1626

Rebuilding of nickel-lang-core is hard to resolve because different crates depend on it with different features enabled.

Lalrpop can't easily be its own crate, because it depends on a bunch of stuff from core. I'm looking into doing something similar to buildDepsOnly in order to only build the lalrpop part and have that ready in the cache.