relay: remove listener streams in `client::Transport`

Description

With #2652 the concept of listeners was removed from the Transport in the sense that having listener streams is not enforced anymore. Instead the transport is responsible for managing its listeners and polling them.

As part of #2652 the relay ClientTransport was adjusted to the trait changes so that now the ClientTransport manages and drives its listener streams. The underlying architecture was not changed and the concept of listeners remains internally.
How it currently works is that:

• for each relayed listening address, we create a new Listener stream and drive it for events
• communication from the Behaviour to the ClientTransport (necessary for informing the Listener of the result of a reservation and of incoming relayed connections) is done via a channel from the Handler (of the connection to the relay) to the Listener
• said channel is created in the ClientTransport, then sent via a channel from transport to behaviour, and then passed from behaviour to the handler.

With the transport changes of #2652, we may be able to reduce the complexity here by removing the listener streams.

The client transport must be aware of the different listeners, but it may not need to drive an extra stream for each listener.
One idea would be to just have one channel between behaviour and transport for each direction and track the necessary states directly in the ClientTransport and Behaviour.
I originally considere to do something like this in #2652, but eventually decided against it because of the reasons described in https://github.com/libp2p/rust-libp2p/pull/2652#discussion_r908166356.

However, I did not look into it in too much detail, and I think it is still worth exploring. Maybe @mxinden you can also give some input here as the original author of the relay_v2 protocol.

Start by reviewing the relay ClientTransport, Listener, Behaviour, and Handler interactions described here, then read the transport changes in #2652 and its linked discussion. Map how listener state and communication channels currently flow; done means the listener-stream architecture has been simplified while preserving reservation and incoming-connection behavior.