Support broadening or narrowing of types in Receivers and Senders

[shsms]

This allows Receivers to reduce message types to be broader than actual, and senders to accept narrower types than required.

    @dataclass
    class Broader:
        """A broad class."""

        value: int

    class Actual(Broader):
        """Actual class."""

    class Narrower(Actual):
        """A narrower class."""

    chan = Broadcast[Actual](name="input-chan")

    sender: Sender[Narrower] = chan.new_sender()
    receiver: Receiver[Broader] = chan.new_receiver()

[Marenz]

LGTM.

[llucax]

I wonder what's the use case for this. This is the case I was thinking of when adding the check_type option to the channel registry with type-checking, but I didn't find any use case. In any case, I think we could merge this, as I guess even if the SDK doesn't have a use case it is a valid relaxation, but I really wonder why you would want to not use the exact same types for sending and receiving.

[Marenz]

Multiple senders from different sources could maybe use different specialized types for the same sender?

[llucax]

OK, I see now this came because of this:

• Power Manager _Report, Report and BatteryPoolReport have the wrong hierarchy frequenz-sdk-python#823