Beta support for Package Runtime Config

[turkenh]

Description of your changes

This PR implements Package Runtime Config (Fixes #4699) as proposed in the design doc with the following exception:

Instead of initializing and maintaining our defaults like replicas: 1 or pod and runtime container securityContext in the DeploymentRuntimeConfig named default, it only initializes an empty DeploymentRuntimeConfig named as default only if it does not exist. It was discussed in the issue in details but this is primarily to avoid the following:

• Creating a new DeploymentRuntimeConfig would require duplicating the values from the default one, assuming the user won't want to lose them. If you only intend to include additional labels, you would need to duplicate the entire default configuration and append labels to the newly created one.
• From now on, the user would need to maintain the defaults in case Crossplane wants to change or extend them in the upcoming releases.
• Since the user could change the default config in time, in the new releases, Crossplane would either overwrite the default DeploymentRuntimeConfig to reflect changes in defaulting or leave the default as is, which would mean Crossplane losing control over defaults.

Considering the above 3 being a degradation over User Experience and Crossplane controlling the defaulting behavior with new releases, I ended up changing it as follows:

• Crossplane will create an empty default DeploymentRuntimeConfig if it does not exist.
• Crossplane will set defaults only if DeploymentRuntimeConfig hasn't set them (i.e. unopinionated). For example, if the deployment replicas is not provided in the config, Crossplane will set the value as 1.
• Crossplane is opinionated about some configurations and will override even if they were provided in the config.

This way, the default DeploymentRuntimeConfig could also be owned by the user without any maintenance burden.

This PR also:

• Refactors existing hooks and manifest generation with a ManifestBuilder.
• Introduces PackageWithRuntime and PackageRevisionWithRuntime interfaces.
• Uses specific package types (Fixes Consider using specific package types #4690).
• Does some clean up including removing the unused controllerRef from PackageRevisionStatus.

See the manifest in the e2e test to get a sense on how DeploymentRuntimeConfig could be customized but still operate properly.

I have:

• Read and followed Crossplane's contribution process.
• Added or updated unit and E2E tests for my change.
• Run make reviewable to ensure this PR is ready for review.
• Added backport release-x.y labels to auto-backport this PR, if necessary.
• Opened a PR updating the docs, if necessary => Document Deployment Runtime Config docs#570

[negz]

Thanks @turkenh!

WRT the design changes, I personally would still vote for what I wrote in #4699 (comment). I prefer moving the default values out of code and into a configuration file. I think this makes it more explicit and predictable, and I think that's worth folks potentially having to copy ~30 lines of YAML to make a new config.

That said, I can accept this as a compromise. It satisfies the primary goal of the design, which was to offer a full template for a Deployment (and potentially in future a Service, ServiceAccount, etc) and I think its cleaner than the other alternatives we discussed.