TestProversMany still fails

odd behavior: only one dht (the last one) is seeing
changes to its routing table.

i made a separate function because we may want to update our
routing table based on "closer peers". maybe not-- these could
all be lies.

Withe queries (particularly providers), it was possible to
exit the query runner's Run BEFORE all its children were done,
because the runner itself only listened to the context. This
introduced the possibility of a panic (you can go check it
out by running the TestProvidersMany test on dht_test in commits
before this one).  Thankfully, ctxgroup saved the day with
almost _zero_ changes to the sync flow, and now we have the
guarantee that the query runner will only exit if all its
children are done. ❤

Conflicts:
	routing/dht/query.go

This commit introduces a reader and writer that respect
contexts. Warning: careful how you use them. Returning
leaves a goroutine reading until the read finishes.

The Peer is Dead. Long live the ID

@jbenet @whyrusleeping

This commit replaces peer.PeerInfo with peer.ID in the bitswap package

@jbenet @whyrusleeping

the next commit will change bitswap.Network.FindProviders to only deal
with IDs

cc @whyrusleeping

This reverts commit bf88f1aec5e3d397f97d64de52b52686cc7a8c8f.

Had to change the network interface from DialPeer(peer.ID) to
DialPeer(peer.PeerInfo), so that addresses of a provider are
handed to the network.

@maybebtc and I are discussing whether this should go all the
way down to the network, or whether the network _should always
work_ with just an ID (which means the network needs to be
able to resolve ID -> Addresses, using the routing system.
This latter point might mean that "routing" might need to
break down into subcomponents. It's a bit sketchy that
the Network would become smarter than just dial/listen and
I/O, but maybe there's a distinction between net.Network,
and something like a peernet.Network that has routing
built in...)

network.ListenAddresses() are general.
Interface addresses are specific.