Include ChaCha pseudorandom generator

This commit introduces a [ChaCha](http://cr.yp.to/chacha.html)-based pseudorandom number generator to librand. Here's why I prefer it to the default, ISAAC:

 - While ISAAC is meant to be cryptographically secure, it stands on relatively shaky ground. Its design is inspired by the much-maligned RC4, and the [existing analysis](https://eprint.iacr.org/2006/438) reveals some suboptimal properties, although not particularly devastating. ISAAC64, the default on 64-bit architectures, doesn't seem to have been analyzed at all.
 - ISAAC has large storage requirements. An ISAAC64 state consumes 4128 bytes, which is ~12.5% of a typical CPU's L1 cache. This ChaCha implementation consumes 144 bytes, and can be further reduced to 105, at the cost of slightly higher implementation complexity. The performance impact of cache hoarding is hard to demonstrate in synthetic benchmarks.
 - ISAAC is inherently sequential, and its speed is somewhat limited by data-dependent memory accesses, not unlike RC4. ChaCha, on the other hand, is not and can be vectorized easily for significant speedups, at the cost of larger state. 

In my tests, an SSE2 (using only what `#[simd]` types allow at the moment) ChaCha20 roughly matches ISAAC in speed, and an AVX2 implementation matches ISAAC64. Better SIMD support (particularly shuffles) would improve these results further. 

I'm currently using the 20-round ChaCha, as originally specified. However, 12 and 8-round variants are also possible (and [believed to be](https://eprint.iacr.org/2007/472) [secure](http://link.springer.com/chapter/10.1007%2F978-3-642-37682-5_24)), and those would provide an additional speedup factor of roughly 20/{12,8}. I have not included SIMD implementations in this commit to avoid the complexity of figuring out which instruction set to use.
I believe this test vector is too short to be hitting the `update` codepath, i.e. it's only testing that it is initialised correctly; could you switch to 


```
   KEY:       000102030405060708090a0b0c0d0e0f101112131415161718191a1b
              1c1d1e1f
   NONCE:     0001020304050607
   KEYSTREAM: f798a189f195e66982105ffb640bb7757f579da31602fc93ec01ac56
              f85ac3c134a4547b733b46413042c9440049176905d3be59ea1c53f1
              5916155c2be8241a38008b9a26bc35941e2444177c8ade6689de9526
              4986d95889fb60e84629c9bd9a5acb1cc118be563eb9b3a4a472f82e
              09a7e778492b562ef7130e88dfe031c79db9d4f7c7a899151b9a4750
              32b63fc385245fe054e3dd5a97a5f576fe064025d3ce042c566ab2c5
              07b138db853e3d6959660996546cc9c4a6eafdc777c040d70eaf46f7
              6dad3979e5c5360c3317166a1c894c94a371876a94df7628fe4eaaf2
              ccb27d5aaae0ad7ad0f9d4b6ad3b54098746d4524d38407a6deb3ab7
              8fab78c9
```

(I think I would prefer to just render the output string to a hexidecimal string, e.g. with the `{:08x}` format specifier, rather than modify the keystream text.)

Alternatively, you could also do something similar to [the ISAAC tests](https://github.com/rust-lang/rust/blob/af3889f6979647b9bd2dc5f5132d80e3e5b405a5/src/librand/isaac.rs#L554-L597), which check the prefix and then check a 'random' subsequence much later (I generated those using a known-good implementation of ISAAC, presumably the same would be done here).