rand: perhaps make an internal rand.RandSource that's concurrent safe to avoid nefarious rand.Seed(1) resets

[odeke-em]

Problem Statement

As a followup to tendermint/tendermint#973, inside some Tendermint repos, we'll see direct invocations of math/rand.R* such as here in:

tmlibs/common/bit_array.go

Line 215 in bfcc021

randElemStart := rand.Intn(length)

https://github.com/tendermint/tmlibs/blob/master/common/bit_array.go#L220
https://github.com/tendermint/tmlibs/blob/master/common/bit_array.go#L235

where we trustingly assumed that at init we properly seeded the random source with

tmlibs/common/random.go

Lines 13 to 21 in bfcc021

	func init() {
	b := cRandBytes(8)
	var seed uint64
	for i := 0; i < 8; i++ {
	seed |= uint64(b[i])
	seed <<= 8
	}
	rand.Seed(int64(seed))
	}

but as shown in issue tendermint/tendermint#973, a couple of our dependencies also set rand.Seed hence if our init gets invoked before theirs, all our initial seeding is no longer useful

Analysis

I think our usages of math/rand.R* are predicated on the ease of use of the stdlib and the fact that the default source guarantees to be concurrency safe but others don't https://golang.org/pkg/math/rand/

Proposed fix

Mirror the functionality of the default source with our own internal RNG seeded with crypto/rand's true randomness and then gut/replace every usage of math/rand in all Tendermint's code