170 merge xnat-web sub chart; 169 Secrets management for DB and plugins

[dean-taylor]

Additions.
Initial deployment security hardening enhancement ensures a Secrets based initial complex password for the initial Admin user. This has replaced the default credentials and removes the need to restrict access during the pre-configuration process.

ISSUE 170
Merged xnat-web sub-chart into xnat/templates/xnat-web
Work around the parser issue of a key containing a hyphen "xnat-web"
Update helper templates and template paths for the new structure

ISSUE 169
Update secrets integration into PostgreSQL configuration.
While secrets can be added via the manifest directly as done previously the addition of a preexisting secret has been provided.
To facilitate configuration and secret merge operations an init container utilises a ConfigMap automatically generated from the config directory in the root folder and with the use of the envsubst command merges Secrets within environment variables. These files are then presented via a read only EmptyDir volume at the required mount point /data/xnat/home/config.
Alterations to some of the default values files have also been updated.
Current best practise involving security hardening has been implemented, including mandating the containers be run as non-root users. This could have implications with deployments that have not set the runAsUser, runAsGroup, fsGroup settings and have filesystems with static UID/GID mappings. E.g. An NFS static provisioned Volume.

[franksc]

../tests/test-postgres.yaml will complain 'A valid postgresql.auth.password is required' if it doesn't find one and helm deploy will fail.

Do we want the out-of-the-box values file to include a sensible default for xnat-web.postgresql so this will work even if deploying user does nothing, e.g. something like this to grab password from the xnat-postgresql secret:

postgresql:
  auth:
    existingSecret: xnat-postgresql
    secretKeys:
      password: password