feat(multiplexer): Allow fine-grained control of concurrency strategy

[scarmuega]

This PR removes the hardcoded threads from inside the multiplexer and provides fine-grained methods for the implementor to decide how to approach concurrency.

A multiplexer is now divided into two different structs: Muxer and Demuxer. Each of this structures provides the following methods:

• tick: to perform a single atomic mux / demux operation.
• block: to enter a continuous loop of muxing / demuxing operations, blocking the thread indefinitely.

To achieve the same thread-based concurrency as before, two helper methods are included as part of the refactoring: spawn_muxer and spawn_demuxer, which creates a thread that performs the corresponding block operation.

Having the low-level operations exposed to the library consumer opens up the possibility to explore other concurrency mechanism:

• no concurrency: single thread where muxer, demuxer and mini-protocols tick sequentially
• single-thread per bearer: use a single thread for muxer / demuxer and different threads for miniprotocols
• async (maybe?): treat each muxer / demuxer loop as a stream of futures
• rayon join mechanism (maybe?): single loop where muxer / demuxer ticks are parallelized only if threads are available