Enable templating of function-managed resources

[kwiatekus]

Description
Improve API of the function spec regarding templating of the sub resources.
Current structure of function spec.template field is not enough for the new use cases that came up ( see the Reason section )

Idea

Currently, we expose the following relevant high level Spec fields:

• Env
• ResourceConfiguration
• ScaleConfig
• Replicas
• Template (Labels)

The high level spec fields should still work.
Users who want to use advanced templating should use two following fields that will be added to the spec:

• RuntimeTemplate
• BuildTemplate

Those fields should be based on a modified PodTemplateSpec.
If defined they should override configuration introduced on higher level spec fields.

Sub tasks

• Implement a reduced PodSpecTemplate-like type as spec.templates.runtimeTemplate and spec.templates.buildTemplate - Implement data type to be used for advanced templating of function managed workloads #15402
• Refactor workload resources part - ☠ Cleanup function-managed workload resources configuration #15737
• Enable management of function-managed workloads' metadata - Allow to define annotations and labels for function managed workloads #14877
• Enable management of function pod's volume mounts - Enable volume mounted secret bindings in Kyma Functions #14998

Reason
Give Serverless users the ability to separate configuration for function deployments and build jobs.
ATM we allow only to pass on the labels and annotations to the function's runtime pod.
We could expand the functionality of the spec.template field and separate templates for pod and build job, so that:

• build job and function pod resources could be defined separately ( under template field )
• passing on annotations to function pod is possible - Allow to define annotations and labels for function managed workloads #14877
• templating of volumes and volume mounts on function pod is possible - Enable volume mounted secret bindings in Kyma Functions #14998

[kwiatekus]

As function is a kind of workload using the term "template" in the spec would cause false expectation that all fields from PodTemplateSpec are configurable via function CRD.
But this is not our goal.

We dont want to confuse users of the API and pretend that we allow to fully configure the pod.
We want to enable some new features :

• enable mounting secrets and config maps - please track here Enable volume mounted secret bindings in Kyma Functions #14998
• enable defining annotiations and labels of function pod - please track here Allow to define annotations and labels for function managed workloads #14877