[chore][VERSIONING.md] Changing protocol support for security is allo…

…wed (#10460)

<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description

<!-- Issue number if applicable -->

We have recently discussed bumping the minimum TLS version to follow
security best practices.
Since we are about to stabilize `configtls` (see #10344), I raised the
question of whether this would be a breaking change that should be done
before 1.0.

I argue that we should be allowed to do this after 1.0 because:
- The Go 1 version compatibility doc states
> Security. A security issue in the specification or implementation may
come to light whose resolution requires breaking compatibility. We
reserve the right to address such security issues.

- The Go team has made [similar
changes](golang/go#45428) in the past for Go
as a whole


While this is not a security issue but a security best practice, the
golang/go issue seems to indicate that changes like this would be in the
spirit of the Go 1 version compatibility promise.

VERSIONING.md

@@ -30,6 +30,7 @@ Unless otherwise specified in the documentation, the following may change in any
  change its output in any way.
 * **Go version compatibility**. Removing support for an unsupported Go version is not considered a breaking change.
 * **OS version compatibility**. Removing support for an unsupported OS version is not considered a breaking change. Upgrading or downgrading OS version support per the [platform support](docs/platform-support.md) document is not considered a breaking change.
+* **Protocol compatibility**. Changing the default minimum version of a supported protocol (e.g. TLS) or dropping support for protocols when there are security concerns is not considered a breaking change.
 * **Dependency updates**. Updating dependencies is not considered a breaking change except when their types are part of the
 public API or the update may change the behavior of applications in an incompatible way.