chore(parameters): update generics names in SSMProvider

[dreamorosi]

Description of your changes

As described in the linked issue, this PR aims at improving the names of some of the types introduced in the previous release (v1.8.0-beta).

The generic names that were used before looked like this:

type SSMGetMultipleOutput<T = undefined, O = undefined> =
  undefined extends T ? 
    undefined extends O ? Record<string, string> :
      O extends SSMGetMultipleOptionsTransformNone | SSMGetMultipleOptionsTransformBinary ? Record<string, string> :
        O extends SSMGetMultipleOptionsTransformAuto ? Record<string, unknown> :
          O extends SSMGetMultipleOptionsTransformJson ? Record<string, Record<string, unknown>> :
            never
    : Record<string, T>;

now, they look like this:

type SSMGetMultipleOutput<ExplicitUserProvidedType = undefined, InferredFromOptionsType = undefined> =
  undefined extends ExplicitUserProvidedType ? 
    undefined extends InferredFromOptionsType ? Record<string, string> :
      InferredFromOptionsType extends SSMGetMultipleOptionsTransformNone | SSMGetMultipleOptionsTransformBinary ? Record<string, string> :
        InferredFromOptionsType extends SSMGetMultipleOptionsTransformAuto ? Record<string, unknown> :
          InferredFromOptionsType extends SSMGetMultipleOptionsTransformJson ? Record<string, Record<string, unknown>> :
            never
    : Record<string, ExplicitUserProvidedType>;

Hopefully these new names are more evocative and better represent what these variables are for.

The PR also refreshes the package-lock.json file.

Once this PR is merged, it closes #1412.

Related issues, RFCs

Issue number: #1412

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding changes to the examples
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.