Identifier fields in spec.initProvider

### What problem are you facing?
As a maintainer of crossplane-contrib/provider-upjet-aws, I often find myself wishing to improve the external name configuration of an existing resource, in cases where the terraform id can be built from the parameters, but the provider is currently using the `IdentifierFromProvider` external name config. This provides usability improvements by allowing a managed resource to assume control of an existing matching external resource, rather than generating an error unless the user explicitly specifies the external-name annotation in the correct but undocumented format for that particular resource kind.

Generally, this results in some of the fields becoming identifier fields, which is appropriate, because they are part of the identifier of the resource. However, as a consequence, they are removed from `spec.initProvider`, which is a breaking schema change.

### How could Upjet help solve your problem?
I can think of three possible solutions, any one of which would make these sorts of external name config improvements easier.

1. Include identifier fields in `spec.initProvider`, and use some sort of merging logic to read from both `initProvider` and `forProvider` when constructing the external name/terraform id.
2. Remove all the `RequiresNew` fields from `initProvider` as proposed in #384, since almost all fields which form part of a terraform resource id are immutable.
3. Make identifier fields optional in both `initProvider` and `forProvider`, and allow upjet to construct the terraform id from the external name (if specified), or from the identifier fields (if the external name annotation is not specified)? I might like this idea best if paired with the "promotion" of the external-name from an annotation to a field like `spec.externalName`, so that we could write validation rules for the identifier fields that require sufficient information to construct the external name if it is not specified.