[Worker Versioning GA]: Add autoUpgrade information inside of events

[Shivs11]

READ BEFORE MERGING: All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted.

• Add InheritedAutoUpgradeInfo message and store it inside of StartWorkflowExecutionAttributes.

• So that replication, on the passive cluster, can also use the revision number mechanics and ensure that workflow tasks get dispatched to the correct worker.

Breaking changes

• Discussion to follow

• Add revision number mechanics for child and CAN workflows temporal#8632

[Sushisource]

Looking good to me. I think the only other things that might be nice to add (but I won't block on):

• How does this interact with versioning_override? I assume override comes first, but good to say.
• Mentioned in my previous review: Does SDK need to care about this? If so how?

[Sushisource]

Suggested change

	// Note: This field is mutually exclusive with `inherited_pinned_version.
	// Note: This field is mutually exclusive with `inherited_pinned_version`.

[Shivs11]

@Sushisource -

1. VersioningOverride will have precedence over this value. I can include that in the docstring in a follow-up commit.
2. [Apologies]. The SDK doesn't need to be interacting with this in any manner. All the checks are being done in the server to ensure that we don't bounce between versions for autoUpgrade workflows.

[Sushisource]

@Sushisource -

1. VersioningOverride will have precedence over this value. I can include that in the docstring in a follow-up commit.

2. [Apologies]. The SDK doesn't need to be interacting with this in any manner. All the checks are being done in the server to ensure that we don't bounce between versions for autoUpgrade workflows.

Super, thanks. Putting that info about SDK into the docstring would probably be good too.