Added the notification channel calls to the client.

[moedash]

This PR adds the notification channel calls to the Python client.

What changed?

• Client.notify_channel, poll_channel, describe_channel, register_channel_listener and unregister_channel_listener. Each one reaches an independent channel, or a channel linked to an owner given as execution= or with the workflow_id= shorthand.
• temporalio.common.Execution and ExecutionType, so a linked channel's owner is a typed value. It can be a workflow or a standalone activity.
• ChannelKind, ChannelListener, ChannelDescription and ChannelAddress, plus the interceptor inputs and OutboundInterceptor methods for the five calls.
• workflow.Notification comes in here on its own, because polls return it. Its linked_to docstring points at workflow.subscribe_channel and workflow.linked_channel, which the next PR adds.
• A changelog entry for the client side.

Part of AI-198 (epic AI-37).

Why?

A channel tells listeners that something they read has moved, and the client is the first place an app touches one. Any process with a client can notify, poll, describe and register a callback without a workflow involved. So this lands before the workflow side, and reviewers see the calls on their own.

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

poe lint is clean. The unit case fakes the service and checks that every call carries the owner it was given, and only then. The callback-listener and retained-poll cases ran against a PoC server that serves channels. On the dev server the fixtures start, they skip.