Adhere to actual semantic versioning rules

[lucix-aws]

AWS SDKs at large do not respect semantic versioning. Up to now, the SDKs and Tools maintenance policy includes verbage that has dictated as such:

Increasing the major version of an SDK indicates that this SDK underwent significant and substantial changes to support new idioms and patterns in the language. Major versions are introduced when public interfaces (e.g. classes, methods, types, etc.), behaviors, or semantics have changed. Applications need to be updated in order for them to work with the newest SDK version. It is important to update major versions carefully and in accordance with the upgrade guidelines provided by AWS.

This is a friction point for customers, because as SDKs we are ultimately not the owner of the APIs we expose in service clients. We do not have the power to prevent service teams from breaking operation signatures (e.g. #2377), or the ability to correct nullability-related issues without breaking within the minor version (bulk changes from #2162). Right now, when changes like these occur, we only bump the minor version, which is a violation of semver guidelines.

Fundamentally we need to decouple the concept of the "product version" from its major version. This will allow breaking changes like the above - in the above scenarios, theoretically we can just release a new major version of that particular service client's module.

Doing this will also enable safer rollout of certain features and avoid issues like that encountered in #2370 (though the underlying issue there is being addressed separately regardless of this, see #2507).

Within this SDK, some of the challenges to consider in effecting this change are:

• What does major versioning look like between client / runtime? How do we address this when we want to make big overhaul-type changes (as described in the maintenance policy snippet above) to the SDK at large
• How to address internally-vended client MVs
• What does the support model look like (past n majors supported? does this carry across broad API overhauls?)

As of this writing, our release system does not have the ability to signal a breaking change in a service (though the information is there and derivable). This would need to be addressed for this to be a possibility for the service clients themselves.

Related: aws/aws-sdk-js-v3#5821