[Feature Request] Eagerly initialize workflow/activity counters

Is your feature request related to a problem? Please describe.

Using prometheus metrics to detect unhappy-path events like workflow failures, or even compute happy-path rates on seldom-executed workflows is made more difficult by the lazy implementation of counters in Temporal SDK metrics. When a workflow fails for the first time, the counter only then begins being reported -- with an initial value of 1.

Prometheus monitoring solutions wishing to alarm on error rates can miss this first increment since prometheus's rate calculation depends upon observing change over time, and a change from non-existence for a counter is undefined. More description of the problem can be found here.

Describe the solution you'd like

For counters that can be known ahead of time, such as for registered worker activities and workflows, I would like to see counters for happy and unhappy-path scenarios eagerly created at the time of registration.

Eager registration would not necessarily apply to dynamic workflows or activities, as they cannot be known ahead of time. However, I would suggest that even for those cases, registration of the corresponding unhappy-path counters should take place immediately at the time the new workflow or activity is discovered, not when it first fails.

I would like to see this at least in the Java SDK, but I am told by @tsurdilo that all SDKs may be affected.

Additional context

Some discussion related to this request took place on the Temporal Slack in this thread.

See prometheus issue #3886 for discussion on how prometheus deals with counters that initially appear non-zero.

No files or tests are named. Start by locating the Java SDK workflow and activity registration paths and their metric initialization logic; determine which counters are created at registration or discovery. Done means known counters exist before the first event, dynamic unhappy-path counters appear when discovered, and affected behavior is covered by tests.