Workflow should have an access to an activity id of the activity it scheduled

Is your feature request related to a problem? Please describe.
There is a scenario when a workflow needs to cancel an activity if it gets an external signal.

For example, an activity sends its own id to some external code and this code has a need to cancel the activity if something happens or finishes before the activity is done.
Right now the only way for an external code to cancel an activity in progress is to send a signal to the workflow that scheduled the activity and the workflow cancels the activity using a cancelation scope after that.

To do that, the activity can't use an activityId, the user needs to create some new correlation id and pass it from the workflow into the activity because an activity code has no way to know an activityId of the activity it just scheduled.

Describe the solution you'd like

1. We create some kind of ActivityInvocationStub for each invocation of an activity. This stub may bind an activityType and any kind of additional parameters we need to set per each invocation. This stub can also expose the activityId. User may not be required to work with such stubs all the time if they don't need them, but they should be available if the user needs them (the same way as untyped WorkflowStubs are implemented)
2. Workflow should be able to generate and pass an activityId into such kind of stub. We should be careful with that, because activityIds in JavaSDK are used to ensure determinism and identify a state machine, so duplicates should be prohibited.

Such a stub should also potentially be able to override ActivityOptions for the specific activity call.

Describe alternatives you've considered
Change nothing and make users pass their own additional ids (and maintain a mapping between these ids to the cancelation scopes or the activities) if they need the workflow to be able to address and cancel an activity later. But there are other reasons to have such stubs: #1009

Additional context
What about timers for example? Should the same apply to timers and their ids?

The issue names no files, tests, or concrete entry points. Start by reviewing the existing untyped WorkflowStub approach and the activity cancellation flow described here, then consider the proposed ActivityInvocationStub, activityId determinism, per-call ActivityOptions, and the related concern in #1009. Done requires a settled API design and clear behavior for activity and possibly timer IDs.