Error reporting for select-based target_compatible_with expressions is too vague

[armandomontanez]

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.

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