Provide extra info of the received signal for re-apply from reset, and others

Is your feature request related to a problem? Please describe.
After reset, the signal reapply is great but sometimes I need to partially reapply to the new run. For example, some signals are from human that are important to keep. Some are not from human and it’s intended to drop so that workflow can behave differently.
This is impossible to do today because there is no way to know if the signal is before or after reset point for reapply.

Additionally, it would be nice to provide info like the time of the signal. This is recorded in history event but not exposed in SDK.

Describe the solution you'd like
It is possible to get this info from history— we have a reset event and then comes with a batch of history to reapply in that batch. So it would be nice if SDK can provide a flag to tell whether or not the signal is from reapply.

The new api may be something like :

type SignalInfo struct{
    FromReapply bool
    SendingTime time.Time
}

info, ok := channel.ReceiveAsyncWithInfo(&val)

Describe alternatives you've considered
Another idea is to let server provide a feature to filter some signals when reapply — maybe based on signal names. But I feel like an SDK feature is better — more flexible and easier to implement

Additional context
Slack thread with Temporal team(Maxim) https://temporalio.slack.com/archives/CTDTU3J4T/p1686762087116689?thread_ts=1686722741.716739&cid=CTDTU3J4T

Start by tracing the SDK signal receive path and how reset history is re-applied. Compare the proposed ReceiveAsyncWithInfo API and SignalInfo fields with the existing signal and history handling. Done means the SDK exposes whether a signal came from reapply and its sending time, with coverage for both cases.