[proposal] Add support for user-defined podTemplate

[andreaTP]

Problem

The user wants to configure a "Kubernetes-specific" setting or add some "infrastructure" to the Deployment created by this operator to fit their own Kubernetes installation needs.
Common use cases are:

• add extra labels/annotations
• specify requests/limits
• mount extra volumes
• add a sidecar/init container
• specify tolerations
• etc...

Relevant open issues:

• make it possible to add Java command line parameters #80
• make it possible to configure requests&limits for cpu&memory for registry pod in ApicurioRegistry CR #79

Motivation

It's hard to predict which "kubernetes features" will be used by users and it's extremely tedious and time-consuming to add them one by one.

Proposal

This proposal proposes a "catch-all" workaround to enable all of those cases removing the need for code changes and manual integration.
More specifically I'm here proposing to support the entire Kubernetes podTemplate to be merged on top of the Deployment currently generated by this operator.
podTemplate have been demonstrated flexible enough to support most of the users needs without the need for special encodings.

Relevant examples:

• Keycloak operator
• Akka operator
• Flink CLI
• Spark CLI

PROS:

• covers all the known use-cases and more

CONS:

• inexperienced users might accidentally compromise functionalities of the operator
• hard if not impossible to predict how all the fields will interact with the default options
• confusion as there are already a few options encoded in the top level of the CRD

Mitigation

A clear documentation regarding this feature and/or a strong advice to use it only after proper testing might help.

Technical implementation notes

Additional challenge

The implementation of podTemplate cannot be easily done automatically as there are a few invariants e.g.:

• when defining property on the container 0 we need to override container 0 fields
• when defining extra containers they should be appended
• when defining commands/args etc. the entire list should be substituted

Experience proves that a careful first implementation of this feature rarely requires complex maintenance.

[jsenko]

Resolved by #212