--incompatible_remove_ctx_apple_fragment

**Motivation**

Part of Starlarkifying native Bazel flags: move language-specific flags out of the Bazel binary and into the rule set's .bzl definitions. This gives rules owners (in this case, primarily `rules_apple`) more ownership over their logic and decouples the flag definitions from Bazel releases.

This Starlarkifies flags previously defined in [AppleCommandLineOptions.java](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/apple/AppleCommandLineOptions.java).

This removes `ctx.fragments.apple`.

**Description**

When flipped, this flag causes Bazel to no longer provide the native `apple` fragment. `ctx.fragments.apple` will no longer exist.

A new `rules_apple` release will use the absence of this fragment as a signal to read all equivalent flag values from Starlark-defined build settings within the `rules_apple` repository.

This is intended to be a user no-op for most Apple builds. However, there are some differences meriting an incompatible flag:

1. Setting Starlark flags requires an equals sign: `$ bazel build //foo --//my:flag=value` must be used instead of `$ bazel build //foo --//my:flag value`. Since we will be aliasing the old native flags to the new Starlark flags, this means users must use the `--flag=value` syntax for the affected Apple flags.
2. Your repository must load `rules_apple` for the Apple Starlark flags to be defined and resolved. This should generally already be true for Apple builds, but could affect scenarios like `select()` statements on Apple flags in non-Apple rules if `rules_apple` isn't loaded.
3. If you have custom .bzl code or aspects that read from `ctx.fragments.apple`, this will break. You need to update your code to read the equivalent Starlark build settings defined in `rules_apple`. Please comment on this issue if you need guidance on mapping old fragment fields to the new Starlark settings.

This change only affects Bazel 10+ (or whatever version this flag is enabled in). Older Bazel versions will continue to work with any version of `rules_apple` (both old and new, assuming the new `rules_apple` maintains backward compatibility for older Bazel versions).

**Incompatible Flag**

`--incompatible_remove_ctx_apple_fragment`

**Migration Guide**

* **If using Bazel 10.0+:** Update to a recent `rules_apple` version that supports Starlark-based flags. Release information for the required `rules_apple` version is TBD. Ensure all invocations of former native Apple flags use the `--flag=value` syntax.
* **If using Bazel <10.0:** No action is needed. The native fragment will still be available.

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

Targeting Bazel 10 (or possibly earlier patch into 9).

**TODO List**

* [ ] Prepare and release the version of `rules_apple` that reads from Starlark settings when `ctx.fragments.apple` is not present.
* [ ] Add flag aliases to `rules_apple/MODULE.bazel` to map old native flag names to the new Starlark settings (e.g., `flag_alias("ios_minimum_os", "//:ios_minimum_os")`).
* [ ] Flip the flag default to true in Bazel.
* [ ] Eventually, remove the native Apple fragment and options class from the Bazel binary.