ci: run optimised tests

[Mirko-von-Leipzig]

Changes CI to build with optmisations (opt-level 2).

This drastically improves test performance, especially prover related tests. This isn't ideal, and requires longer compile times, but the trade off at the moment is definitely worth it. Test compile time went up for deps but since they're usually cached this is okay. Test runtime went from ~15 minutes to 2.

On my local machine, tests time went from over 6 minutes, to 15s.

Important to note that we could do much better ito compile time if the optimisations could be restricted to a subset of dependencies. Unfortunately as noted in #2002 this isn't practically possible due to late monomorphisation of prover generics, so we always have miden-remote-prover as a requirement.

---

Additionally, I noticed that this rebuild took forever because the cache was useless. However all jobs had to rebuild from scratch because the build job only saves its cache when its pushed to next to not flood github cache. This is correct but means the current build is never shared, only the latest trunk's build.

I changed this to share the artifacts directly between the current job. Each trunk has a base cache, which is used by build. build then creates a run specific cache, which gets deleted at the end of the run to spare cache capacity.

---

I originally had this change only for CI. But I think this is probably useful for dev setup as well so I made it broader.

[Mirko-von-Leipzig]

The overall slow CI runtime is mostly because the existing rust cache is useless since we change opt-level in this PR. So there is no base cache.

[kkovaacs]

It'd be cool to avoid forcing this for all dependencies -- compile times are quite bad with these settings.

Is there any chance we could avoid surfacing prover generics from our dependencies?

[Mirko-von-Leipzig]

It'd be cool to avoid forcing this for all dependencies -- compile times are quite bad with these settings.

Is there any chance we could avoid surfacing prover generics from our dependencies?

That would be my preference as well. We can probably narrow down our dependency set further (as in, change "*" to some set of deps. But compile time hit will remain until we don't have the generics on our side I think.

I did some tweaks in #2002 but I don't know the proper place to really fix this. Its a bit crazy to me that we have plonky-related generics in our final exe.