Add OpenTracing interceptor for standalone activities

[444am]

What was changed

Added OpenTracing support for standalone activity client operations.

Why?

Standalone activities can be started and managed through ActivityClient, but the OpenTracing contrib module did not trace those client operations. This adds tracing
coverage consistent with the existing workflow client and worker tracing patterns.

Standalone activity execution also needs its own worker-side run span because standalone activities do not have workflow IDs or workflow run IDs.

How was this tested:

See 2 UT files for Client and Worker respectively.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[444am]

ActionName has to be set for getSpanName(), but ActivityType is not provided in GetActivityResultInput / DescribeActivityInput etc. To minimize the cardinality I'm using a fixed placeholder here as of now. Let me know if you believe repeatedly using activityId for distinction would be better.

[cconstable]

Hey, thanks for this PR! I think we should merge this but we should bring it inline with the other SDKs first.

1. We should only create tracing spans for StartActivity. list, count, terminate, describe, etc are plain request/response or list/count calls that do not have meaningful latency boundaries, don't propagate trace headers, and are a bit noisy. The other SDKs intentionally do not track these and we should stay consistent with that.
2. We can reuse StartActivity + RunActivity (i.e. don't introduce StartStandaloneActivity + RunStandaloneActivity). There are no "standalone" variants in the other SDKs. We distinguish by tags and not by span names. For reference, see https://github.com/temporalio/sdk-python/blob/main/temporalio/contrib/opentelemetry/_interceptor.py#L373
3. For the worker interceptor, we should keep a single RunActivity span and vary the tags instead of forking on isInWorkflow(). For reference, Python's execute_activity emits one RunActivity span and conditionally adds the workflow attributes if we are in a workflow.

so the span builder would change to be something like this:

case RUN_ACTIVITY: {
    ImmutableMap.Builder<String, String> tags = ImmutableMap.builder();
    if (context.getActivityId() != null) tags.put(StandardTagNames.ACTIVITY_ID, context.getActivityId());
    if (context.getWorkflowId() != null) tags.put(StandardTagNames.WORKFLOW_ID, context.getWorkflowId());
    if (context.getRunId() != null)      tags.put(StandardTagNames.RUN_ID, context.getRunId());
    return tags.build();
  }

4. Lastly, we should add a README snippet showing how to register this.

Does that all sound reasonable? Lmk if you have more feedback or if you aren't able to make the changes and I can get to it sometime in the next few days. Again, appreciate the PR!

[444am]

Hi @cconstable , thanks for the comments, those make sense. I've updated my PR to address your comments.

For README, I also changed previous "Client configuration" to "Workflow Client configuration". LMK if that aligns with your convention.