Support labeling targets with minimum-compatible C++ version

### Description of the feature request:

I would like a standard way to tag a target (library, binary, or test) as requiring a minimum C++ version (e.g. C++20 and above).

Related features:
- `target_compatible_with`: C++ version isn't quite a property of the platform, and there isn't a standard way to detect it, since it may be configured via any of: (1) target `copts` (2) command-line `--copts=-std=c++14` (3) `copts` in the toolchain definition. Even when working with a single one of these, there's no general mechanism for `select`-ing for "C++20 or greater."
- [Enable setting C/C++ standards as a toolchain feature](https://github.com/bazelbuild/bazel/issues/16551). This feature doesn't make it clear how to avoid building the (e.g.) C++20-only target when building the rest of the repo with a C++14 toolchain.
- [C/C++ standard resolution for Bazel modules](https://docs.google.com/document/d/132vEDnQZY0PtF9ko6HoLQ2dqk6meZnSrUfc1gsKuBkk/edit) (cc @fmeum). This is a bzlmod-module-level mechanism, so it only works if the whole module declares a minimum version. I'd like something more granular (target-level).

cc @tpudlik @trybka

### Which category does this issue belong to?

C++ Rules, Core

### What underlying problem are you trying to solve with this feature?

I work on a project that supports C++17. However, we'd like to offer C++20 coroutine support for users that are using C++20. I'd like to be able to declare a coroutine-compatibility target which only builds (and is only tested) when C++20 or later is enabled. Those particular library and test targets should not be built or run when using C++17.

One solution would be to `#ifdef` out the entire files such that the tests and library target still built and ran on C++17, but this would create the mistaken impression that the tests were building and running successfully, which I don't want. All dependent targets would also have to `#ifdef` themselves out of existence. Additionally, users attempting to depend on my target from C++17 would encounter an opaque error (missing symbols on import) rather than a useful one.

Start by reading the related target_compatible_with, C/C++ toolchain feature, and Bazel modules discussions linked in the issue, then trace how C++ rules obtain their configured standard. The feature is done when a target can declare a minimum C++ version, incompatible targets are not built or tested, and dependencies receive a useful error under an older standard.

Written by the indexing model from the issue text.