refactor: use interface references in public api (awslint:ref-via-interface)

[eladb]

Adds a new awslint:ref-via-interface rule which validates that all input APIs
(e.g. props, method arguments) use construct interface (IBucket) and not concrete
classes (Bucket). This is in order to enable passing in unowned resources and
in accordance with the aws construct library guidelines.

There are situations where an owned resource is required. In those, the rule
can be disabled by adding [disable-awslint:ref-via-interface] to the element's
inline documentation.

To enable this, the following new construct interfaces were added, along with fromXxx import methods:

• applicationautoscaling.IScalableTarget
• cloudwatch.IAlarm
• ecs.IService
• ecs.IEc2Service
• ec2.IFargateService
• ecs.ITaskDefinition
• iam.IGroup
• iam.IUser
• iam.IPolicy
• lambda.IVersion

Fixes #2412

BREAKING CHANGE: apigateway.ResourceBase.trackChild is now internal.

• cloudfront.S3OriginConfig.originAccessIdentity is now originAccessIdentityId
• codedeploy.LambdaDeploymentGroup.alarms is now cloudwatch.IAlarm[] (previously cloudwatch.Alarm[])
• codepipeline.crossRegionScaffoldingStacks renamed to crossRegionScaffolding
• codepipeline.CrossRegionScaffoldingStack renamed to codepipeline.CrossRegionScaffolding and cannot be instantiated (abstract)
• ec2.VpcSubnet.addDefaultRouteToNAT renamed to addDefaultNatRoute and made public
• ec2.VpcSubnet.addDefaultRouteToIGW renamed to addDefaultInternetRoute, made public and first argument is the gateway ID (string) and not the CFN L1 class
• ecs.Ec2EventRuleTarget.taskDefinition is now ITaskDefinition (previously TaskDefinition)
• lambda.IEventSource.bind now accepts IFunction instead of FunctionBase. Use IFunction.addEventSourceMapping to add an event source mapping under the function.
• lambda.Layer.grantUsage renamed to lambda.layer.addPermission and returns void
• stepfunctions.StateMachine.role is now iam.IRole (previously iam.Role)

---

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.

[mergify]

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

• PR title type(scope): text
  • type: fix, feat, refactor go into CHANGELOG, chore is hidden
  • scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
  • text: use all lower-case, do not end with a period, do not include issue refs
• PR Description
  • Rationale: describe rationale of change and approach taken
  • Issues: indicate issues fixed via: fixes #xxx or closes #xxx
  • Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
• Testing
  • Unit test added. Prefer to add a new test rather than modify existing tests
  • CLI or init templates change? Re-run/add CLI integration tests
• Documentation
  • README: update module README to describe new features
  • API docs: public APIs must be documented. Copy from official AWS docs when possible
  • Design: for significant features, follow design process