`spec.container` and `spec.service.container` consolidation

[Crumby]

Having two API field to manage pods container related configurations is confusing and it's not clear which configuration should target which part of the API.

From the historical perspective spec.service.container was meant to be used with DataGrid service type which is already the only one currently support (and thus irrelevant). On the other side spec.container was meant to be used with any service type: Cache and DataGrid.

Configuration options:
spec.container: cpu, memory, extraJvmOpts. cliExtraJvmOpts, routerExtraJvmOpts
spec.service.container: storageSize, ephemeralStorage, livenessProbe, readinessProbe, startupProbe, terminationGracePeriod

Options:

1. Completely new InfinispanV2 CRD
2. Consolidate one under the other one

Ad 1. Given we have already other deprecated API it would ideal to come up with InfnispanV2 CRD. Nevertheless that would mean extensive amount of work

Ad 2. Simpler solution which will increase amount of deprecated fields in the CRD though and extends boilerplate to accommodate for the changes

[ryanemerson]

I have considered a InfinispanV2 in the past and my conclusion was that the known and unknown pains associated with this were not worth it. I think we would need a very compelling reason before adopting this approach, as the Operator associated with Infinispan 16 will be around for a long time and this also has downstream lifecycle implications.

If we went with 2, I would suggest that we deprecate spec.service.container and add all of it's fields to spec.container. The webhook can then automatically convert from spec.service.container -> spec.service fields.