Recover fallback on server configuration when resourceLabels are not specified

[mark-hofmeijer]

What was changed

This PR recovers the possibility to define resource labels on server level (e.g. server.podLabels) rather than only within the scope of the server services (frontend, history, matching, worker).

Why?

With the introduction of resourceLabels templatization (#539), the option to specify podLabels on server level has been discontinued. Presumably this was not done consciously.

In the old situation it worked as follows:
{{- with (default $.Values.server.podLabels $serviceValues.podLabels) }}
(source: https://github.com/temporalio/helm-charts/pull/539/files#diff-b8142966d328045abc62158c9a0c7b8492a97eb135757aea4a6941d4a80edb9e)

But in the new situation, in case the component equals server only the resource labels (e.g. server.frontend.podLabels) within the scope are used. If not specified, any values in server.podLabels are ignored.

Checklist

1. How was this tested:
   helm install -f values.yaml --set server.frontend.podLabels.resourceLabel1="resourceTest1" debug . --dry-run --debug

• This should add a label resourceLabel1 to the temporal-frontend deployment.
• This is the case in both the current and the new situation.

helm install -f values.yaml --set server.podLabels.serverLabel1="serverTest1" --set server.frontend.podLabels.resourceLabel1="resourceTest1" debug . --dry-run --debug

• This should add a label resourceLabel1 to the temporal-frontend deployment.
• This is the case in both the current and the new situation.

helm install -f values.yaml --set server.podLabels.serverLabel1="serverTest1" debug . --dry-run --debug

• This should add a label serverLabel1 to the temporal-frontend deployment (and other server services).
• In the current situation no labels are added to any of the server services.
• In the new situation label serverLabel1 is added to all server services.

2. Any docs updates needed?
   No.