Use build artifacts to reduce the amount of duplicate building on CI machines

[tt-rkim]

Some things to watch out for:

• We currently embed -rpath into our test executables and SOs. This means there's a hardcoded path in these binaries, specifically $TT_METAL_HOME/build/lib, from the machine that built them. We'll need to ensure that the consumer machines take the produced binaries and link properly with the local version of $TT_METAL_HOME/build/lib. Like with UMD tests, I think easiest path here is LD_LIBRARY_PATH. Even if we use the same machine build and upload artifacts, it might still be a good idea to ensure LD_LIBRARY_PATH is set. Open to suggestions
• We currently link against stuff that we install on GitHub runners in the existing build artifacts pipeline. Theoretically, if we installed the deps correctly, it shouldn't be a problem. We do install all deps listed in the README on the runner. As a reference: https://github.com/actions/runner-images/blob/ubuntu20/20240225.1/images/ubuntu/Ubuntu2004-Readme.md If we strictly use our own runners, then we won't have to worry about this
• The current artifacts pipeline could be refactored out into one that builds ci on our hardware and all the other configs on GitHub runners.

[tt-rkim]

@TT-billteng I added some changes that should help with this to main.

We only bake in rpath in dev environment. We should therefore:

• build artifacts in non-dev environment
• Use LD_LIBRARY_PATH or some similar mechanism to link against downloaded artifacts

[TT-billteng]

initial changes are in main, will do some clean up next week