Re-organising crate structure

Pitch

The current workspace and dependency structure is heavily guided by its own history. We've moved around many components since it was created and refactored various interfaces. It is time to take a step back and look at the code holistically to organise it in such a way that code that changes together lives together. This will help with:

• Making fewer breaking changes: For example, no more breaking changes in protocols unless the NetworkBehaviour interface changes.
• Better compile times: Smaller, cohesive crates means more parallelism during the compilation phase
• Easier to understand: Currently, it is unclear what the purpose of libp2p-core is other than "stuff that everything depends on"

Vision

libp2p wants to be a modular networking stack. To make this easy, users need to be able to maintain their own libp2p-compatible networking out-of-tree without much friction. This requires somewhat stable interfaces which we are hoping to provide with this restructuring.

Approach

I've already outlined some ideas in https://github.com/libp2p/rust-libp2p/discussions/3072#discussioncomment-4394785. This issue is to track concrete work items into getting there. The basic idea is to break up libp2p-core and libp2p-swarm into more focused crates that provide minimal interfaces that are required for interoperability.

The following list tries to be ordered. Untangling dependencies can be tricky so I am probably going to miss something. In case someone picks up an item, keep that in mind :)

- [x] https://github.com/libp2p/rust-libp2p/issues/3349
- [x] https://github.com/libp2p/rust-libp2p/issues/3748
- [ ] https://github.com/libp2p/rust-libp2p/issues/4011
- [ ] https://github.com/libp2p/rust-libp2p/issues/3953
- [ ] Move transport utilities to `libp2p-swarm` or `libp2p`
- [ ] Move `Transport` to its own crate: `libp2p-transport`
- [ ] Move upgrade traits to `libp2p-swarm`. Upgrade utilities should go into their own crate
- [ ] Merge `SignedEnvelope` and `PeerRecord` into `libp2p-identity`?

Start by reading the linked discussion comment and the remaining unchecked work items, especially issues 4011 and 3953. Trace the current workspace dependencies around libp2p-core and libp2p-swarm, then coordinate a focused restructuring item; done means the selected crate split or merge is implemented without breaking the intended modular networking interfaces.