Error reporting for select-based target_compatible_with expressions is too vague

### Description of the bug:

Due to limitations with `config_setting` rules used in `target_compatible_with` (also see https://github.com/bazelbuild/bazel/issues/12614), I use a lot of `select`-based `target_compatible_with` expressions. Unfortunately, this usually means the error messages that are presented are inscrutable:
```
@@pico-sdk~1.6.0-rc1~_repo_rules~btstack//:pico_btstack_base (d6a49d) <-- target platform (@@pico-sdk~1.6.0-rc1//bazel/platform:rp2040) didn't satisfy constraint @@platforms//:incompatible
```

The actual `config_setting` branch that is evaluated here is named nicely: `"@pico-sdk//bazel/constraint:pico_btstack_config_unset"`, but because of how the `select` is evaluated, that pathway never gets surfaced. The technical limitation here is pretty obvious, but perhaps we can reorient this problem a bit and consider ways to allow developers to provide friendly error messages here? I'd love to get something like this:
```
ERROR: Analysis of target '//examples:hello_world_pico' failed; build aborted: Target //examples:hello_world_pico is incompatible and cannot be built, but was explicitly requested.
Dependency chain:
//examples:hello_world_pico (9d7924)
//examples:hello_world_pico.elf (d6a49d)
@@pico-sdk~1.6.0-rc1//src/rp2_common/pico_cyw43_arch:pico_cyw43_arch_none (d6a49d)
@@pico-sdk~1.6.0-rc1//src/rp2_common/pico_cyw43_arch:pico_cyw43_arch_threadsafe_background (d6a49d)
@@pico-sdk~1.6.0-rc1//src/rp2_common/pico_cyw43_driver:pico_cyw43_driver (d6a49d)
@@pico-sdk~1.6.0-rc1//src/rp2_common/pico_btstack:btstack_run_loop_async_context (d6a49d)
@@pico-sdk~1.6.0-rc1~_repo_rules~btstack//:pico_btstack_base (d6a49d) <-- target platform (@@pico-sdk~1.6.0-rc1//bazel/platform:rp2040) didn't satisfy constraint @@platforms//:incompatible
ERROR: BT stack was not properly configured, please set --@pico-sdk//bazel/config:PICO_BTSTACK_CONFIG to point to a library that provides BT stack configuration options and defines at least one of `ENABLE_CLASSIC=1` or `ENABLE_BLE=1`
```

At a minimum, it'd be nice to get some sort of actionable output here, but in the bigger picture there's a lot of libraries that require manual configuration before use and it'd be AMAZING if library authors could manually provide helpful error messages.

### Which category does this issue belong to?

Configurability

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

```py
cc_library(
name = "foo",
target_compatible_with = select({
"//conditions:default": ["@platforms//:incompatible"],
}),
)
```

### Which operating system are you running Bazel on?

_No response_

### What is the output of `bazel info release`?

_No response_

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

_No response_

### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

_No response_

### Have you found anything relevant by searching the web?

_No response_

### Any other information, logs, or outputs that you want to share?

_No response_

Start with the minimal cc_library example and the target_compatible_with/select evaluation path described in the report. Reproduce the vague incompatibility output, then trace the Bazel analysis code that formats this diagnostic. Done means an actionable, user-provided message can be surfaced without losing the existing constraint information, with coverage for the example.

Written by the indexing model from the issue text.