refactor(core): revisit the Stack API

[eladb]

Fixes #2728

BREAKING CHANGE:

• core: stack.name renamed to stack.stackName
• core: stack.stackName will return the concrete stack name. Use Aws.stackName to indicate { Ref: "AWS::StackName" }.
• core: stack.account and stack.region will return the concrete account/region only if they are explicitly specified when the stack is defined (under the env prop). Otherwise, they will return a token that resolves to the AWS::AccountId and AWS::Region intrinsic references. Use Context.getDefaultAccount() and Context.getDefaultRegion() to obtain the defaults passed through the toolkit in case those are needed. Use Token.isUnresolved(v) to check if you have a concrete or intrinsic.
• core: stack.logicalId has been removed. Use stack.getLogicalId()
• core: stack.env has been removed, use stack.account, stack.region and stack.environment instead
• core: stack.accountId renamed to stack.account (to allow treating account more abstractly)
• core: AvailabilityZoneProvider can now be accessed through Context.getAvailabilityZones()
• core: SSMParameterProvider can now be accessed through Context.getSsmParameter()
• core: parseArn is now Arn.parse
• core: arnFromComponents is now arn.format
• core: node.lock and node.unlock are now private
• core: stack.requireRegion and requireAccountId have been removed. Use Token.unresolved(stack.region) instead
• core: stack.parentApp have been removed. Use App.isApp(stack.node.root) instead.
• core: stack.missingContext is now private
• core: stack.renameLogical have been renamed to stack.renameLogicalId
• core: IAddressingScheme, HashedAddressingScheme and LogicalIDs are now internal. Override Stack.allocateLogicalId to customize how logical IDs are allocated to resources.

---

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.

[inakianduaga]

@eladb Hi, I'm trying to figure out a way to easily remove the logicalId prefix to all the resources within a stack, and found

aws-cdk/packages/@aws-cdk/core/lib/stack.ts

Line 247 in 82e08bc

* override the `createNamingScheme` method.

/**
   * Rename a generated logical identities
   *
   * To modify the naming scheme strategy, extend the `Stack` class and
   * override the `createNamingScheme` method.
   */
  public renameLogicalId(oldId: string, newId: string) {
    this._logicalIds.addRename(oldId, newId);
  }

however I don't see any reference to createNamingScheme anywhere else, nor does it get used by CDK when I provide one. Is this outdated? (this is on CDK v1.4 BTW)

[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