Implementation proposal: support Temporal server pprof profiling

[Azerothian]

Source: alexandrevilain#705 - "temporal's pprof utility"

I would like to enable temporal's pprof utility, but it does not seem that it is supported by temporal-operator at this time... would you consider a PR?

Why it fits: pprof is the standard way to profile Temporal server components; the operator owns the pod specs and config generation, so exposing it is squarely operator work and helps debug production memory/CPU issues in frontend/history/matching.

Proposed implementation:

• Add optional pprof block under the services config, e.g. spec.services.<service>.pprof.enabled (bool, default false), translating to the Temporal dynamic config / env vars that enable pprof on each service.
• When enabled, add the pprof container port to the pod spec so kubectl port-forward profiling works; optionally expose it on the per-service Service behind the same flag.
• Keep it opt-in per service to avoid widening the attack surface by default.

Affected areas: api/v1beta1 (services spec), deployment builder for frontend/history/matching/worker, config/env generation, CRD manifests, docs.

Risks: low - purely additive, default-off. Port naming must not collide with existing container ports.