SwarmBuilder generics are too restricting

Description

SwarmBuilder is too restricting when I want to conditionally user some features.
For example:

let mut swarm = SwarmBuilder::with_existing_identity(key_pair)
            .with_tokio()
            .with_tcp(Default::default(), noise::Config::new, yamux::Config::default)
            .expect("Error building TCP transport")
            .with_dns()
            .expect("Error building DNS transport")
            .with_behaviour(|key| {
                mixed_behaviour::MixedBehaviour::new(
                    key.clone(),
                    bootstrap_peer_multiaddr,
                    sqmr::Config { session_timeout },
                    chain_id,
                    node_version,
                    discovery_config,
                    peer_manager_config,
                )
            })
            .expect("Error while building the swarm")
            .with_swarm_config(|cfg| cfg.with_idle_connection_timeout(idle_connection_timeout))
            .build();

If I want to sometimes use QUIC instead of TCP, and sometimes log, and sometimes use this behaviour or another I cannot do this incrementally by adding to the builder.

Motivation

It allows for making a slightly different swarm depending on the required parameters.

Current Implementation

pub struct SwarmBuilder<Provider, Phase> {
    keypair: libp2p_identity::Keypair,
    phantom: PhantomData<Provider>,
    phase: Phase,
}

The builder takes a generic provider and phase which change the object after setting each layer, which means that after diverging with one layer I can no longer have a variable that holds the builder because the type is ambiguous

Are you planning to do it yourself in a pull request?

Yes

Start by reading the current SwarmBuilder definition and its generic Provider and Phase parameters shown in the issue. Trace how each builder layer changes those types, then determine a design that permits conditional TCP or QUIC transports, logging, and behaviours while preserving incremental building; done means these variants can be selected without an ambiguous builder variable.