[KOGITO-9265] Add PodSpec customization guide

[ricardozanini]

JIRA:
https://issues.redhat.com/browse/KOGITO-9265

Description:
In this PR, we add a new guide to explain the new feature able to customize PodSpec in SonataFlow CR.

Depends on:

• [KOGITO-9265] Add the PodSpecTemplate to the SonataFlow CR incubator-kie-kogito-serverless-operator#255

Please make sure that your PR meets the following requirements:

• You have read the contributions doc
• Pull Request title is properly formatted: KOGITO-XYZ Subject
• Pull Request title contains the target branch if not targeting main: [0.9.x] KOGITO-XYZ Subject
• The nav.adoc file has a link to this guide in the proper category
• The index.adoc file has a card to this guide in the proper category, with a meaningful description

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.

If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

[rgolangh]

so the container instead of containers is a deviation on purpose from k8s podTemplate right?

[rgolangh]

will the rest of the spec.resources be mounted into that container at runtime? this is defintely the expectation.
In other words it should automatically populate the volumes list in the template.

[ricardozanini]

Hey @rgolangh! We can, though it won't at this moment. We should discuss this use case since we don't have a build, hence the resource won't be in the application's classpath (included in the jar). We should definitely understand where to mount these resources in this situation.

I'll add a note about this in this PR.

I've opened a JIRA for us to discuss: https://issues.redhat.com/browse/KOGITO-9845

[MarianMacik]

Looks good!