Opt in to breaking changes

**Related command**

For example:

```sh
az postgres flexible-server firewall-rule create \
--rule-name "Allow_${MY_NAME//[^a-zA-Z0-9]/_}_$DATE" \
--start-ip-address "$MY_IP" \
--resource-group "$MY_RG" \
--name "$MY_SERVER"
```

**Is your feature request related to a problem? Please describe.**

Running a `postgres flexible-server` subcommand with a `--name` argument produces a warning such as:

```text
WARNING: The --name/-n argument will be repurposed to specify the firewall rule name. The --server-name/-s argument will be introduced to specify the server name in next breaking change release(2.86.0) scheduled for May 2026.
WARNING: The --rule-name/-r argument has been deprecated and will be removed in next breaking change release(2.86.0) scheduled for May 2026.
```

I've written some automation for my team that drives the Azure CLI and other commands.

There doesn't appear to be any action I can take to future proof my script and explicitly opt in to the new argument handling. This confuses users of my script who see the warning and think something is wrong.

**Describe the solution you'd like**

It would be useful to have a global flag that allows me to opt in to a particular future breaking change version. This would allow for a graceful transition of automation using the Azure CLI and allow scripts to be forward compatible with the new breaking version at its time of release.

**Describe alternatives you've considered**

Currently, I have to:

- Accept the warnings and explain what they mean to users of my script
- Ensure the Azure CLI version is pinned to the current version for all of my users, including people installing it for the first time after the 2.86.0 release
- Synchronize upgrading my script and the required Azure CLI version for all of its users

**Additional context**

The particular changes I'm affected by were introduced in #32560, but this applies generally to all breaking changes.