Add apiConfig to aws.api#tagEnabled for renamed tagging operations

[taylorlo-aws]

Background

• What do these changes do?

Allow services that model tagging via non-default operation names (e.g., AddTagsToResource instead of TagResource) to keep validation and tag discovery on. The new TaggableServiceApiConfig structure has three optional ShapeID slots (tagApi, untagApi, listTagsApi); each unset slot falls back to the default-named operation. Resource-level apiConfig still wins over service-level for resource-bound resolution.

AwsTagIndex now resolves the per-service tagging op slots via the service-level apiConfig before falling back to default-named lookups. A new TagEnabledServiceValidator check warns when an apiConfig override coexists with the default-named operation in the service operations list, so modelers either drop the override or remove the dead op.

• Why are they important?

Services like RDS use service level tagging operations that are not named the default. This change allows the usage of tagEnabled to semantically associate these non-standard tagging APIs in the model so that consumers can find them while still applying the existing validation.

Testing

• How did you test these changes?

All existing model test cases pass; this change is backwards compatible. New model test cases were added to validate the new override + fallback behavior.

Links

• Links to additional context, if necessary

N/A

• Issue #, if applicable (see here for a list of keywords to use for linking issues)

N/A

---

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