Close redundant connections

This branch makes two changes to help us stay within the Bluetooth connection limit:

1. Add a new priority record to the sync protocol. One priority record is sent over each duplex connection by the peer that opens the connection. The record contains a random number. If we have more than one connection to a given contact over the same transport, we keep the highest-priority connection and close the others. This mechanism is designed so that if Alice and Bob open connections to each other at roughly the same time (or if one of them opens two connections at roughly the same time), they won't choose different connections to close and end up with no connections.

2. Prefer LAN connections to Bluetooth connections. If we're connected to a given contact via LAN then we won't poll for connections to that contact via Bluetooth, and conversely if we're connected via Bluetooth and we manage to make a LAN connection, we'll close the Bluetooth connection. This mechanism is triggered by exchanging priority records, so that if our contact is running an old version of Briar that doesn't know about transport preferences or priorities, they won't try to replace the connections we close.

I chose LAN over Bluetooth because it has higher bandwidth, no connection limit, and a similar threat profile (leaks metadata to a local adversary, unobservable to an internet adversary). Whether we should prefer LAN to Tor, or Tor to Bluetooth, depends on the user's threat model. But those preferences can easily be added later if we decide we want them.

Part of #1712 (closed)