fix(cloudwatch): move SNS Alarm Action to aws-cloudwatch-actions

[rix0rrr]

In accordance with new guidelines, we're centralizing cross-service
integrations into their own package. In this case, centralizing
CloudWatch Alarm Actions into @aws-cdk/aws-cloudwatch-actions.

Not moving AutoScaling classes because doing so would introduce circular
dependencies.

BREAKING CHANGE: using an SNS topic as CloudWatch Alarm Actxion now
requires an integration object from the @aws-cdk/aws-cloudwatch-actions
package.

---

Pull Request Checklist

• Testing
  • Unit test added (prefer not to modify an existing test, otherwise, it's probably a breaking change)
  • CLI change?: coordinate update of integration tests with team
  • cdk-init template change?: coordinated update of integration tests with team
• Docs
  • jsdocs: All public APIs documented
  • README: README and/or documentation topic updated
  • Design: For significant features, design document added to design folder
• Title and Description
  • Change type: title prefixed with fix, feat and module name in parens, which will appear in changelog
  • Title: use lower-case and doesn't end with a period
  • Breaking?: last paragraph: "BREAKING CHANGE: <describe what changed + link for details>"
  • Issues: Indicate issues fixed via: "Fixes #xxx" or "Closes #xxx"
• Sensitive Modules (requires 2 PR approvers)
  • IAM Policy Document (in @aws-cdk/aws-iam)
  • EC2 Security Groups and ACLs (in @aws-cdk/aws-ec2)
  • Grant APIs (only if not based on official documentation with a reference)

---

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

[eladb]

The name of the return type is not super consistent across integrations, ha? Should we standardize?

[rix0rrr]

It should be Properties. I didn't want to call it Props because it's not a "Props" object as such, but I may have failed to rename in one PR somewhere.

Another potential candidate is Attributes.

Your preference?

[eladb]

I think it would make sense to use a different suffix to distinguish between those and initialization props, which have a very specific role in our framework. How about “Settings” or “Config”?

[eladb]

I am also okay with Attributes.

[sorry just saw your previous comment asking for my preference]

[eladb]

Change suffix

[eladb]

Actually, we already use Attributes for the fromXxxAttributes, so "Config" I guess?

[rix0rrr]

Gosh darnit.

Just spent 1.5hrs renaming everything to "Props" :(