Factor some common testing infrastructure for evaluating yamux and mplex.

Example usage of FindNetworkLimit is to wrap it in a test, e.g.

func TestSmallPackets(t *testing.T) {
	slowdown, err := test.FindNetworkLimit(testSmallPackets)
	if err != nil {
		t.Fatal(err)
	}
	if slowdown > 0.01 {
		t.Fatalf("Slowdown from was >1%%: %f", slowdown)
	}
}

Tests will be added in go-libp2p-yamux and go-libp2p-mplex wrapping this. example output looks something like:

$ go test -run TestSmallPackets . -cpu 4 -v -benchtime 10s
go test -run TestSmallPackets . -cpu 4 -v -benchtime 10s
=== RUN   TestSmallPackets
CPU Bound Limit:   756516	     15630 ns/op	14714113.83 MB/s
Latency Bound Limit: 1ms
Bandwidth Bound Limit: 102400Kbps
Network Bound Limit:   667627	     18475 ns/op	10986033.14 MB/s
At MaxProc 1 10240Kbps / 5ms latency:    51513	    234283 ns/op	66800.22 MB/s
At MaxProc 2 10240Kbps / 5ms latency:    51474	    233296 ns/op	67018.94 MB/s
At MaxProc 4 10240Kbps / 5ms latency:    51253	    467991 ns/op	33285.00 MB/s
Slowdown is 0.372082%
--- PASS: TestSmallPackets (68.04s)
PASS
ok  	github.com/libp2p/go-mplex	68.664s

The basic mechanism this harness is implementing is first identifying how much the boundary between CPU-bound and Network-bound limitations of a given testing operation. Then, on the network-bound side of that boundary, increasing parallelism and watching the ratio of how utilized the network link is.

Notes: the output from the wrapped testing.Benchmark calls don't account for threads/processes properly - the reported ns/op and MB/s does a racy division on number of spawned threads, as far as i can tell. it ends up not particularly useful, but the overall bytes pushed over the network is bench-marked correctly across parallelism.