feat/ci: workflow adjustments to use rocksdb.a precompiled

[drahnr]

Uses a static rocksdb library (rocksdb.a on Linux, we only build on Linux), except for publish-related CI runs.

Why

We spend significant time on building the same artifact repeatedly, and

What

1. small fix for recently introduced binaries that didn't have the C++ std lib linkage fix setup correctly
2. fix for test runs to also include C++ std lib where relevant (via miden-node-util)
3. adds a GHA workflow to build a rocksdb.a static library, and use that in conjunction with the "right" env vars to skip build - we also skip caching rocksdb (C++) build artifacts which saves us a good chunk of cache, once used uniformly.

Open questions:

1. since build using cargo b -p librocksdb-sys@{{ version }} --locked we will build the exact same library, so we might want to unify the approach to publish-* workflows as well - I think we should

[drahnr]

@Mirko-von-Leipzig this is going to conflict quite a bit with your refactor into a single file (in a "good way" in a sense)

[Mirko-von-Leipzig]

@Mirko-von-Leipzig this is going to conflict quite a bit with your refactor into a single file (in a "good way" in a sense)

How would you like to go about it? I think after mine makes sense because it simplifies your diff here iiuc? But of course I'm biased 😁 I don't mind if you'd prefer to go ahead with this first.

We could also forgo this PR entirely and see whether the caching changes are dramatic enough to not care about this?

[drahnr]

Please merge your's first, I'll do some comparison of cache+time afterwards

[Mirko-von-Leipzig]

Do you think this is still worth adding to CI runs? Right now all large jobs here build on top of the build job which should already mean compiling this only once due to shared caching.

[drahnr]

I think we'd safe on link-time, but there is complexity penalty adding.
Haven't checked the "savings" if any just yet.