all: rewrite the entire tor network to eventual consistency

[karalabe]

This PR is a complete rewrite of the tornet overlay P2P networking layer:

• User identities (encryption and authorization) were replaced, instead of relying on ecdsa, the new code uses ed25519 curves. This permits us to use deterministic signatures, so TLS certificates can be regenerated on the fly and don't have to be shuffled around. This in its turn permits us to reduce the pairing secret from 200 something bytes to 64.
• Onion cryptography uses standard Go packages to manage the private keys instead of relying on the bine package. At the end of the day we still convert it to a bine key due to a limitation in it (Go's ed25519 package was only recently included in the stdlib). Need to upstream support for proper ed crypto.
• A protocol handshake magic was introduced to mutually validate handshakes and certificates before any actual data is even attempted to be exchanged.
• The old tornet.Node was split into individual components that are each surfaced through the APIs, permitting a much more orthogonal design. Server represents the onion listener part; PeerSet the connection handling; and Node a combination featuring address rotation.
• Automatic connectivity is not included any more in tornet to cater for battery operated scenarios, instead the application needs to explicitly request connections (all other functionality are still automagic). In a similar vein, the new tornet includes a connection breaker that an tear down idle streams to avoid the Tor maintenance burden.

The entire corona network application was reworked to operate on top of the new tornet:

• Pairing uses Server and PeerSet directly, without address rotation or bi-directional trust. This new scheme permits us to only share the public onion address, not the private key, removing one potential MitM attack vector.
• The entire networking subsystem was refactored based on better Tor behavior experiments. From now on the overlay is not torn down and restarted every time the user disables/enables Tor, rather it's constructed once and only Tor's network is flipped. This allows internal onions and keyrings to be handles much more uniformly and stably. More importantly, it allows all networking endpoints to be async since Tor will take care of all the messy setups and self-healing in the background.
• With on-demand connectivity, this PR also introduced the initial groundwork for the "eventual consistency" model where the backend does not rely on instant update propagation (unless there's an active connection to a peer), rather it uses priorities to schedule future dials based on how important an update is.

Fixes #24
Fixes #22