[feature]: consider balances when picking outgoing channel

[C-Otto]

When my node is asked to forward a payment to some other peer, lnd is responsible for picking the outgoing channel that is used for the payment.
If several parallel channels exist, lnd currently picks a channel at random.
I'd like lnd to also consider the local and, possibly, remote balances on the channels, so that certain problematic situations can be avoided or fixed.

Current behavior:
Implemented in https://github.com/lightningnetwork/lnd/blob/master/htlcswitch/switch.go#L1224

The current implementation evenly spreads the load of HTLCs on all (eligable) channels.
This includes disk space consumption (num_updates, number of updates any watchtower might need to track).
I think this also includes the risk/cost associated with force-closing a channel, assuming it suffices to force-close just one of the parallel channels.

In addition I'd like to explain other reasons why picking a specific channel might be in the noderunner's and the network's best interest.

1. Optimizing for routing potential

For example, consider the case that two parallel channels, both of size 1 BTC = 100M sats, exist.
I'd rather have the liquidity split 0%/100% and 100%/0% instead of 50%/50% on both channels, so that a payment of size 90M can be forwarded or received without having to rely on split payments (MPP).

This example can be extended to any number of parallel channels, of varying sizes.

The desired effect can be achieved by always routing via the channel that has the lowest local liquidity ("bandwidth"), but enough for the requested payment.

2. Avoiding reserve issues

See #7108. The channel initiator needs to have some liquidity even to receive payments, so that the additional HTLC can be paid for if the channel needs to be force-closed. In other words, if I opened the channel and only have a few sats on my side of the channel, I should not use this channel for outgoing payments (assuming there's a better alternative).

If the outgoing channel is picked so that channels low on funds are avoided (possibly limited to those where the local node is the initiator), it's more likely that the channel can be used to receive payments.

Similarly, logic could be added to help fix this issue on the remote side of the channel: pick a channel where the remote side is low on funds (possibly limited to channels initiated by the remote peer). If the payment is small enough ("dust"), this can even be used to fix a channel that is currently blocked from receiving larger payments.

PS: Please also have a look at #5972.