Support providing Registry notification headers as Kubernetes secrets

Logic

1. Move registry notifications to global. This is because we may need to pass the header to Rails application too.
2. We use an array (of maps) to list headers, not a map (of maps) like original registry configuration. This is a visible difference. This was changed.
3. We do not transform contents of secret to an array, but just place its contents as value to the header key. It is on the user to populate the secret in the proper format (array of strings).
4. Sensitive and regular headers are distinguished by the keys in the map. If there is a key value, we deem it to be a regular one. If there is a key secret, we deem it to be a sensitive one. type of the value. If it is a map, we assume it is a secret-backed one, else, we assume it is a regular one.
5. Regular headers are placed as-is in the config file.
6. Sensitive headers are placed as <name>: SECRET_<secret name>_<secret key> in the config file.
7. We mount the sensitive headers to the registry configuration directory, under a subdirectory called notifications in the format SECRET_<secret name>_<secret key>.
8. In the initContainer, we do a find-and-replace on SECRET_* strings with the contents of the respective files in notifications subdirectory. This is similar to how we handled httpSecret, ACCESS_KEY, SECRET_KEY etc.

Closes #1969 (closed)