re-add the V1 of client config version

[Amplifiyer]

Problem

V1 was replaced with V1.1 in this PR #1742 that caused a breaking change for clients that were using generateClientConfig programmatically.

Issue number, if available:

Changes

This PR adds V1 back. Renamed the 1.1 version as V1_1 in the code nomenclature (namespace and methods etc)

Note: there is a hard dependency that all fragments of the client config be on the same version, so if a customer is using a new backend-cli version (V1.1 of outputs) but trying to generate the outputs for V1, they have to ensure to pass the version in the backend.addOutput() call as the default there is always the latest one.

Corresponding docs PR, if applicable:

Validation

Checklist

• If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
• If this PR requires a change to the Project Architecture README, I have included that update in this PR.
• If this PR requires a docs update, I have linked to that docs PR above.
• If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[changeset-bot]

🦋 Changeset detected

Latest commit: e723559

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@aws-amplify/client-config	Minor
@aws-amplify/backend	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[sobolk]

LGTM.

I think we should expand this test to cover programmatic read of outputs. It would prevent the problem I think. (or perhaps combine with approach used here where we assert that old version can be read by new).
If you agree, please log github issue.

[Amplifiyer]

LGTM.

I think we should expand this test to cover programmatic read of outputs. It would prevent the problem I think. (or perhaps combine with approach used here where we assert that old version can be read by new). If you agree, please log github issue.

#1918