refactor(core): use "string" for physical name props

[eladb]

We realized there is no need to use a strong type (PhysicalName) for resource physical names. Eventually users want to be able to either use the default, pass an explicit string for the name or request that the framework generate a name for them, conditionally (or, in the future, unconditionally) to whether the resource is being referenced across environments.

To that end, all physical name props have been converted back to string and a special token marker PhysicalName.GENERATE_IF_NEEDED was introduced which can be used to indicate that physical name will be generated if needed for cross environment references.

This change also modifies the protected API provided the Resource class:

• physicalName returns the value that should be passed to the CFN resource
• getResourceNameAttribute(nameAttr) returns a token that should be exposed as the resource name (e.g. bucketName).
• getResourceArnAttribute(arnAttr, components) returns a token that should bexposed as the resource's ARN (e.g. bucketArn).

All of these are "environment-sensitive" and will return "the right" value, depending on the resource's poster and configuration.

---

Please read the contribution guidelines and follow the pull-request checklist.

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