fix os_images_info_input_hash to ensure that os-images-info is updated after os_images_info_input_hash upgrade

os_images_info_input_hash, which controls whether or not the os-images-info ConfigMap needs to be re-run on an upgrade, was computed in a wrong way. This hash is meant to take as input all the data given to the create-os-images-info script, in particular the output of the generate-os-images named template.

The issue is that the strings used to compute os_images_info_input_hash are passed into toJson | sha256sum before having been interpreted, so what is hashed is the following string:

- '{{ .Chart.Version }}'
- |2-
      os_images:
        ubuntu-jammy-plain-rke2-1-28-9:
          sylva_dib_image: true
          uri: '{{ .Values.sylva_base_oci_registry }}/sylva-elements/diskimage-builder/ubuntu-jammy-plain-rke2-1-28-9:{{
            .Values.sylva_diskimagebuilder_version }}'
- '{{ .Values._internal.default_os_images_info_configmap }}'
...
- .cluster.local: true
  .cluster.local.: true
  .svc: true
  '{{ printf ".%s" .Values.cluster_domain }}': true
  10.0.0.0/8: true
  127.0.0.1: true
  172.16.0.0/12: true
  172.20.129.142: true
  192.168.0.0/16: true
  localhost: true
- true

... without any substitution of the {{ ... }} things by the interpreter. This is due to the fact that we do not control in which order items of _internal are interpreted.

So if on an upgrade sylva_diskimagebuilder_version changes (or .Chart.Version), the hash will not change, and the resulting compute map will still have information for the previous sylva_diskimagebuilder_version, and no OS image update will happen on the cluster.

This MR fixes that by ensuring that proper interpretation happens before hashing.

Doing that involved quite a bit of changes and was the opportunity for cleanups:

• (1) the named templates in _os-images.tpl were partly working with uninterpreted data -- this data was interpreted later when rendered into final resources, so this was ok -- but to simplify the computation of the os-images-info hash, it was good to fix that
• (2) the name used for the os-images-info ConfigMap was dynamic following this hash -- this was done in 9f5ed698 / !1433 (merged) -- and made the code around this pretty complex, but now that we constraint Kustomization reconciliation during updates thanks to the global root-dependency-<n> dependency, this isn't necessary -- this MR simplifies that
• (3) given (2), we don't need to compute the hash in _internal

(this MR is a resubmission of !2396 (merged) which had mistakenly been merged and then reverted in !2400 (merged))

Closes #1316 (closed)