cquery with starlark output uses wrong label for alias targets

### Description of the bug:

https://bazel.build/extending/platforms#cquery-incompatible-target-detection gives the following snippet as the canonical way of filtering incompatible targets:

```console
$ cat example.cquery

def format(target):
if "IncompatiblePlatformProvider" not in providers(target):
return target.label
return ""

$ bazel cquery //... --output=starlark --starlark:file=example.cquery
```

Unfortunately, `target.label` returns the label of `actual`, not the `alias` itself, for `alias` targets:

```console
% cat java/example/BUILD.bazel
alias(
name = "example_test",
actual = ":ExampleTest",
)

java_test(
name = "ExampleTest",
srcs = ["ExampleTest.java"],
)
% USE_BAZEL_VERSION=6.2.0 bazel cquery --output=starlark '--starlark:expr=target.label if "IncompatiblePlatformProvider" not in providers(target) else ""' ... 2>/dev/null
@//java/example:ExampleTest
@//java/example:ExampleTest
```

The repr of the target contains both pieces of information:
```console
% USE_BAZEL_VERSION=6.2.0 bazel cquery --output=starlark '--starlark:expr=target if "IncompatiblePlatformProvider" not in providers(target) else ""' ... 2>/dev/null

```

I would expect `target.label` to return the actual label of all targets, and for any alias lookup to require looking at a specific property or provider, rather than automatically passing through.

`AliasConfiguredTarget` explicitly overrides `getLabel` to have this behaviour, https://github.com/bazelbuild/bazel/blob/277d05ffe65dd563fc1e5dd7edf8c707f5ef0685/src/main/java/com/google/devtools/build/lib/rules/AliasConfiguredTarget.java#L126-L129

AFAICT the quick way to fix this would be to use a custom `StarlarkSemantics` for cquery, and override `Object getValue(StarlarkSemantics semantics, String name)` on `AliasConfiguredTarget` so that `getValue(CquerySemantics, "label")` returns the original label not the aliased one. I suspect actually changing any of the behaviours of `getLabel` anywhere else would be a huge scary change...

It's worth noting this isn't the first time this has come up - see https://github.com/bazelbuild/bazel/blob/6c1487caf624923f6ab52255f077d3e8dad62080/src/main/java/com/google/devtools/build/lib/query2/cquery/ConfiguredTargetQueryEnvironment.java#L465-L473 and https://github.com/bazelbuild/bazel/blob/6c1487caf624923f6ab52255f077d3e8dad62080/src/main/java/com/google/devtools/build/lib/query2/aquery/ActionGraphQueryEnvironment.java#L181-L186

/cc @lberki as the author of `AliasConfiguredTarget`, @gregestren and @fmeum as cquery --output=starlark folks.

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

_No response_

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

_No response_

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

release 6.2.0

### 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 master; git rev-parse HEAD` ?

_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 AliasConfiguredTarget.java and the cquery Starlark handling described in ConfiguredTargetQueryEnvironment.java; compare the existing label behavior with the provided alias reproduction command. Trace the related aquery handling noted in the issue. Done means cquery Starlark output preserves an alias target's label while retaining the actual target relationship.

Written by the indexing model from the issue text.