`--incompatible_eagerly_resolve_select_keys`

### Motivation

If a `select` is constructed by a macro and refers to fixed targets via label string keys, these labels will be resolved relative to each usage of the `select` value in a BUILD file. This differs from the behavior of attribute defaults and is a common gotcha - with Bzlmod, how a label resolved crucially relies on the repo it is being resolved from.

### Description

With `--incompatible_eagerly_resolve_select_keys` enabled, `select` calls from `.bzl` files will instead resolve label strings in keys relative to the containing `.bzl` file. This behavior can be matched by explicitly wrapping each key in `Label(...)` (or `str(Label(...))` for compatibility with old versions of Bazel that don't support `Label` in `select` keys).

### Incompatible Flag

--incompatible_eagerly_resolve_select_keys

### Migration Guide

`select` usages in `BUILD` files are not affected.

If a macro dynamically constructs `select` keys that are meant to be evaluated relative to the calling BUILD file, for example because it also instantiates `config_setting`s that it then references in a `select`, the keys will have to be wrapped in `native.package_relative_label(...)`.

### In which Bazel LTS version will this incompatible change be enabled?

Bazel 9

### Additional Context

_No response_

### TODO List

_No response_