Allow encouraging (or forcing) dials with specific properties

Nobody has claimed this yet.

## What

The current contract around `Connect` and `NewStream` delegates basically all control over how to form the connection to go-libp2p. This is a feature request for additional capabilities indicating a preference of how a connection might be formed.

## Why

For example:
- What if a user felt that for some workloads they'd prefer TCP over QUIC despite some of the tradeoffs (e.g. if TCP throughput exceeds QUICs for some data transfer heavy workloads)
- What if a user knew that a particular network interface happened to be faster/cheaper for them (e.g. addresses in the same cloud provider network)
- What if a user wanted to do some debugging using a node with lots of transports supported, but only wanted to use one of them
- This is effectively the issue in https://github.com/ipfs/kubo/issues/9895
- Note: As mentioned in that issue doing debugging this way can be difficult and doing debugging in that particular way likely has issues beyond the go-libp2p ones. Feedback welcome if you feel I've missed anything in https://github.com/ipfs/kubo/issues/9895#issuecomment-1624539885
- IIUC to some extent AutoNAT could operate this way, but we're ok spinning up a slimmed down separate host anyhow for these shortlived operations and "just make a new host" ends up being the required pattern for other sorts of services like this. It's not clear to me whether this pattern being mandatory is deemed a hack or intended. It feels a little like the former though.

## How

The three mechanisms I'm aware of that can enable this are:
1. For pass/fail type behavior it might be possible for this to exist in user-space with some hackery around connection gaters, except for the fact that we might return if there is already a connection open.
2. Information could be passed into the dialer via contexts, such as more versions of https://github.com/libp2p/go-libp2p/blob/cfc50bae8e49a00ed531a0f49e0357011ba68a83/core/network/context.go#L28
3. Using some overriding of the dialer logic with something explicit, like https://github.com/libp2p/go-libp2p/blob/cfc50bae8e49a00ed531a0f49e0357011ba68a83/options.go#L581
4. More functions on the host that have explicit guarantees

None of these are enough as-is today to implement the above, however it seems likely some combination 2 + 3 would be able to get the job done.

For example, if either the DialRanker could take a context or the context could carry a custom dialer then most of the logic here could live in application space. There could also be a similar type of configuration around contexts for if a new connection should be used and a ConnectionRanker.

## Why (file this issue) Now

I haven't heard a ton of requests for these features although they do come up from time to time. However, the coincidental timing of the linked kubo issue (from someone familiar with go-libp2p and kubo 😄) and the recent smart-dialer work made me think this could be useful to put on the radar in case it ends up being easier to make changes to now rather than later (e.g. should the DialRanker take a context, and should it be overridable on a per Connection/Stream basis).

Start by reading core/network/context.go and options.go at the referenced dialer entry points, then trace the recent smart-dialer work. Done means an agreed mechanism for expressing per-dial connection preferences or enforcement, with tests covering existing and requested connection behavior.

Written by the indexing model from the issue text.