[FEATURE] Introduce a mechanism for detecting and incorporating breaking changes from spec in a backward compatible way

Is your feature request related to a problem?

Today, the Java client can include breaking changes in each release, as it is generated from the latest spec updates and does not always take prior Java client versions into account. This can make backward compatibility and future evolution more difficult.

What solution would you like?

Java client should introduce some kind of versioning / compatibility matrix / backward compability support (e.g. marking old fields as deprecated but not fully removing them until the next OS major version release), to support correctness fixes coming from the upstream source of truth opensearch-api-specification.
As a general principle, downstream consumers (e.g. java client, opensearch-protobufs) should not block upstream (i.e. opensearch-api-specification) from being updated.

What alternatives have you considered?

Any solution that allows independent evolution and autonomy of the opensearch-api-specification will suffice.

Do you have any additional context?

The java client today is also tightly coupled with specific syntaxes / ways of representing the spec, which is not ideal. e.g. this PR https://github.com/opensearch-project/opensearch-api-specification/pull/956 was reverted in the spec repo by https://github.com/opensearch-project/opensearch-api-specification/pull/1011 , despite reducing redundancy and using the correct REST API representation, because it broke java code generation

Start by reviewing how the Java client is coupled to the opensearch-api-specification and the referenced specification pull requests 956 and 1011. Done should mean the client can incorporate upstream correctness changes while preserving compatibility with prior Java client versions and allowing deprecated fields to remain until the stated release boundary.