feat: add additionalInitContainers support to Qdrant StatefulSet

[naveenkumarsp]

Problem

The chart provides no hook for custom init containers. Operators needing
one-shot node-level setup before Qdrant starts (e.g. raising
vm.max_map_count to avoid ENOMEM on mmap-heavy deployments with many
collections and shards) are forced to use workarounds:

• A privileged sidecar — no ordering guarantee, must sleep infinity
  to stay alive alongside Qdrant.
• A separate DaemonSet — decoupled from the pod lifecycle, requires
  node pool label coordination.

Solution

Add additionalInitContainers to values.yaml (default []). Entries
are appended after the existing ensure-dir-ownership init container in
the StatefulSet template, so they run sequentially before Qdrant starts.

Changes

• templates/statefulset.yaml — render additionalInitContainers after
  the ensure-dir-ownership block.
• values.yaml — add additionalInitContainers: [] with a fully
  commented real-world example (vm.max_map_count) and guidance on when
  to prefer init containers over sidecarContainers.

Example usage

additionalInitContainers:
  - name: set-vm-max-map-count
    image: busybox
    command: ['sysctl', '-w', 'vm.max_map_count=262144']
    securityContext:
      privileged: true
    resources:
      requests:
        cpu: 1m
        memory: 1Mi