Consider how multiple hosts can be specified when establishing a connection

Currently, we only allow a single host/port pair to be passed to the `connect()` call. To make building HA setups around the binding(s) easier, we should allow passing a list of addresses to be tried in order. On its own, this would satisfy simple HA setups with static hostlists, either direct server addresses or load-balancing proxy lists.

For reference, PostgreSQL's libpq documentation on how to specify multiple hosts is [here](https://www.postgresql.org/docs/10/libpq-connect.html#LIBPQ-MULTIPLE-HOSTS).

Their approach is hybrid: `host` and `port` are separate arguments and both may contain lists. If `host` and `port` are both lists, they must be of the same size, if `host` is a list and `port` is not, the specified port is applied to all hosts.

The upside of this approach is that it keeps things simple in the very common case of a single host/port, and the downside is that separate `host` and `port` lists are harder to specify and manage.

An alternative approach is to remove the `port` argument and instead allow passing `host` as either a string, a single (named) tuple, or a list of (named) tuples.

All of this applies to how the `credentials` file is structured, since we want to keep the resemblance with `connect()` call signatures.

Start by reviewing the connect() API and the credentials file handling, then compare the two proposed representations with the linked PostgreSQL multi-host behavior. The work is complete only after one representation is selected and multi-host connection attempts are consistently supported in both interfaces.

Written by the indexing model from the issue text.