feat(chart): support additionalContainers as a map

[wpjunior]

What

Allow deployment.additionalContainers to be specified as a map in addition
to the existing list format. When a map is provided, each key becomes the
container name; the list format continues to work exactly as before.

# Map format (new) — key becomes the container name
deployment:
  additionalContainers:
    sidecar:
      image: busybox
      command: ['/bin/sh']

# List format (still supported)
deployment:
  additionalContainers:
    - name: sidecar
      image: busybox
      command: ['/bin/sh']

Why

Map-keyed values are far easier to override and patch per-container in GitOps
tools such as ArgoCD, where merging into a keyed map is deterministic while
merging into a positional list is not. This mirrors the map style already used
elsewhere in the chart (initContainers, envFrom, volumes, ...).

How

• templates/deployment.yaml: detect the value kind with kindIs "map". For a
  map, range the entries and merge (dict "name" $name) $container; for a
  list, keep the previous rendering. Empty map/list renders no extra containers.
• values.yaml: document both formats and annotate the type as
  (list, object, null) so the generated schema validates correctly.
• values.schema.json: regenerated → type: [array, object, null].
• README.md: regenerated via helm-docs.

Tests

• Added unit tests in tests/deployment_test.yaml covering: list format, map
  format (key → name), multiple map entries, and the empty-map case.
• Converted the additionalContainers example in ci/values.yaml to the map
  format so snapshot tests and Kind API validation exercise the new path.
  Rendered output is byte-identical to the list form (snapshots unchanged).

Backwards compatibility

Fully backwards compatible — the list format is unchanged; the map format is
purely additive.

[wpjunior]

HI @aslafy-z and @rasheedamir what do you think about this MR?

[aslafy-z]

Thank you for your contribution, please address the following comment so we can proceed.

[aslafy-z]

application/tests/deployment_test.yaml

Could you drop the YAML anchors here and write the asserts out literally?

This is test code, and in tests we want to minimize logic and indirection: each test should be readable standalone, as plain input and expected output. Duplication is fine here, an anchor is not worth the extra hop.

• &additionalContainersAsserts I get the intent (list and map formats should render the same container), but the map-format test no longer says what it asserts, you have to jump back to the previous test to find out. Duplicating the four-line assert block states the equivalence just as clearly and reads inline.
• &containersPath is also inconsistent with the rest of the file: spec.template.spec.containers is spelled out ~25 times elsewhere, and even the last test added in this PR (the empty-map notContains case) writes the path literally instead of reusing the alias. Aliasing it in only three spots saves nothing and breaks grep for the path.

Anchors as a convention would only make sense applied consistently across the test files, and I don't think that churn is worth it either way given the point above about keeping tests logic-free.

[aslafy-z]

One more thing on the tests: could you use the placeholder image convention instead of real images (busybox, nginx)? #596 normalizes it across the suite: example-registry/example-image:example-tag for the main container (it is the suite fixture at the top of deployment_test.yaml) and another-example-registry/another-example-image:another-example-tag for any additional image (init containers, image templating tests). For the sidecar tests here that means the another-example-* form; in the multi-container test you can vary the tag or mix the example-* / another-example-* components so the two entries stay distinguishable. Renovate's ignoreDeps already covers all these combinations. Once #596 is merged a rebase is worth it anyway, since it renames the fixture values in deployment_test.yaml.