Adds capability to add generic labels for all sidekiq objects

What does this MR do?

Introduces an option that helps apply a set of labels spread across all objects associated with the GitLab Sidekiq chart. Given the following:

global:
  common:
    labels:
      baz: "bat"
gitlab:
  sidekiq:
    common:
      labels:
        foo: "bar"

The label set baz=bat is applied to all objects created by the GitLab Sidekiq Chart (this is to expand to encompass all objects in the future, but this MR is already large). The label set foo=bar is applied to all objects for only the GitLab Sidekiq Chart, should any keys be repeated by the user, they'll be merged and the item provided in gitlab.sidekiq will take precedent. This ensures that persons wanting labels they are able to add as they need and it is applied to all objects that are query-able.

There are additional methods we can apply labels to various objects.

global:
  common:
    labels:
      qux: quux
  pod:
    labels:
      foo: bar
gitlab:
  sidekiq:
    podLabels:
      garply: waldo

We expect to see all labels appropriately applied to the necessary objects, merging items taking precedent the closer we get to the object being created. The general format is, we'll apply a pod label for the sidekiq chart to the Deployment, which takes precedent over a label given to the global pod labels, which takes precedent over the global common labels. Perhaps better summarized via the below:

• gitlab.sidekiq.podLabels > gitlab.sidekiq.common.labels > global.pod.labels > global.common.labels => Applies to the Deployment object for the GitLab Shell
• gitlab.gitlab-shell.common.labels > global.common.labels => Applies to essentially all other objects other than the above.

Note that we do not interfere with the standard set of labels that we generate in the _application.tpl. Users will still have the chance of creating labels that may interfere with each other, but the possibility should be low as the items generated in the _application.tpl are geared towards the helm release information.

Should labels be repetitive, helm will NOT bail, Kubernetes will NOT throw a warning, instead Kubernetes will take in the last key value pair in the label hash.

Related issues

#2465 (closed)

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Merge Request Title and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added
• Integration tests added to GitLab QA - n/a
• Equivalent MR/issue for omnibus-gitlab opened - n/a