Once NpgsqlDataSource is integrated, we can reimplement multiplexing

• This represents multiplexing exactly where it is API-wise: at the database/pool level, not associated to any particular connection instance.
• This would make it impossible to accidentally depend on connection state, which isn't supported in multiplexing (e.g. 45270fa)
• It would considerably simplify our internal code, since we'll no longer have to deal with bound/unbound connections - connections are always bound. Instead we'd just have a MultiplexingNpgsqlCommand (internal type) which implements the multiplexing logic.
• I think we still want multiplexing to be opt-in on the connection string.

Note: if we no longer support multiplexing on NpgsqlConnection (which we ideally shouldn't), then EF Core and other layers must react and use DbDataSource in order to get the perf benefits of multiplexing.