[libc++] Decouple building libc++ from testing libc++ in the CI

Originally from https://github.com/llvm/llvm-project/pull/193045#pullrequestreview-4155899291.

I think it would be generally beneficial to split up our CI to represent the two axis that actually exist in reality:
- The configuration used to build libc++.dylib (exceptions? RTTI? hardening mode?)
- The configuration when using libc++ (aka how the developer builds their own code)

This would allow properly testing the real configuration matrix that we support. We could have a set of CI jobs that build libc++ in various configurations and store it in the Github Actions temp storage, and then a set of jobs that download that and test it in various other configurations. Doing that properly will require a generalization of our existing Lit features though (e.g. `no-exceptions` becomes meaningless, since we need to specify whether the dylib is no-exceptions or the user code is no-exceptions).

Start by examining the existing libc++ GitHub Actions CI jobs and Lit features mentioned in the issue. Map the current build and test configurations, then determine how jobs can share built libc++.dylib artifacts while distinguishing library and user-code settings; done means both configuration axes are independently exercised.

Written by the indexing model from the issue text.