Allow removing litep2p from dependencies

[nazar-pc]

litep2p causes multiple issues downstream for us at Subspace. Older release brought vulnerable ed25519-dalek version that we had to suppress in cargo audit, now I noticed it pulls a large number of extra dependencies, including OpenSSL that I was trying to avoid all this time and was pretty successful at it.

The fact that it it enabled by default and not possible to disable is very undesirable, please consider making it an option just like it is possible to disable RocksDB right now for databases.

[nazar-pc]

While it seems that litep2p is here to stay for better or worse, it is at least possible to configure transports with paritytech/litep2p#192 that should ideally be ported over here as well so we can simply not enable protocols we are not interested in downstream.

[nazar-pc]

#5562 is related to this one

[bkchr]

CC @paritytech/networking

[kayabaNerve]

I did this on my (arbitrarily opinionated) fork of Substrate: serai-dex@e7fe70f

It's incredibly feasible, barring the fact that union multihash API is premised on pre-0.19 while libp2p ships multihash 0.19. I found the easiest solution to inline multihash 0.18 instead of wrapping libp2p's multihash. In immediate hindsight, I'd have saved a dependency, and made things a bit simpler, by wrapping multihash 0.17 (as litep2p re-exports).

I personally was quite interested in this issue, but became less so as litep2p matured and seemed to start hitting performance targets. I believe my current complaints, and justification for this, resolve to the distinct dependency tree of notable size. While a potentially worthwhile trade-off for redundancy/performance, I did want to work on evaluation with solely libp2p before I made a decision there within my own work.