Update API_VERSIONING.md to remove ambiguity. (#40022)

I thought the original statement is kind of ambiguous "...Envoy and the
larger xDS ecosystem ...is too widely used to make version bumps
realistic." could be understood as "too widely used" as a facilitator of
version bumps (instead of a barrier to version bumps).

One could also have said "...Envoy and the larger xDS ecosystem ...is
too widely used to make version bumps unrealistic." where "too widely
used" is being presented as a barrier to version bumps.

I just rewrote to make it absolutely clear

Signed-off-by: sanjaypujare <[email protected]>

Mirrored from https://github.com/envoyproxy/envoy @ bd8ff0930d96d27ac2c19bdf26a47df06baa88cf

Author: update-envoy[bot]

API_VERSIONING.md

@@ -80,10 +80,10 @@ implementations within a major version should set explicit values for these fiel
 
 At one point, the Envoy project planned for regular major version updates to the xDS API in order to
 remove technical debt. At this point we recognize that Envoy and the larger xDS ecosystem (gRPC,
-etc.) is too widely used to make version bumps realistic. As such, for practical purposes, the v3
-API is the final major version of the API and will be supported forever. Deprecations will still
-occur as an end-user indication that there is a preferred way to configure a particular feature, but
-no field will ever be removed nor will Envoy ever remove the implementation for any deprecated
+etc.) is so widely used that version bumps are no longer realistic. As such, for practical purposes,
+the v3 API is the final major version of the API and will be supported forever. Deprecations will
+still occur as an end-user indication that there is a preferred way to configure a particular feature,
+but no field will ever be removed nor will Envoy ever remove the implementation for any deprecated
 field.
 
 **NOTE**: Client implementations are free to output additional warnings about field usage beyond