Sha1 and Sha2 cleanups & optimizations

UPDATED (7/29): Rebased out the MD5 implementation and updated the Sha1 implementation instead.

I reworked the Sha2 code to be more readable and faster. Part of that work entailed extracting out common code having to do with buffer handling into a new struct, FixedBuffer, in the new cryptoutil.rs file. I then updated the Sha1 implementation to use the new functionality.

The first 3 commits in this request just move stuff around in the sha2.rs file. None of the changes here should impact functionality, but hopefully make the code a bit cleaner and easier to work with.

In the 4th commit:
* I create the FixedBuffer struct. This struct contains the logic to gather up input bytes until a full block is available. Once that full block is available, its fed into a passed in closure, which in the case of a hash function is the compression function and the buffer is then marked as empty. The existing Digest implementations tend to do a lot processing a byte at a time and tend to do more copies than necessary - the FixedBuffer class tries to do just the minimum amount of copying possible. My hope is that this struct can be used by any future Digest implementation (at least those that are block based).
* I added in a few unsafe methods to optimize some common cases - writing an integer to a [u8] and reading in an array of integers from a [u8]. These methods verify their preconditions explicitly and will cause an assert! if they are used in a manner that would corrupt memory.
* I updated the Sha2 code to make use of all this new functionality. This resulted in a nice speedup in my benchmarks.
* I greatly reduced the size of the Sha2 objects - previously they contained their entire working buffer - 80 u64s for Sha512 and 64 u32s for Sha256, even though they are only needed for calculation by the compression function; with this change I allocate those larger buffers on the stack in the compression function.

In the 5th commit, I rewrite the compression functions used by Sha2. Not a major change - I inlined the message schedule calculation into the same loop as the rest of the compression function. This results in a nice speedup as I believe it lets LLVM optimize the method better. 

In the 6th commit, I update the Digest trait to use default methods and get rid of the the DigestUtil trait now that default methods seem to be working better.

The 7th commit adds a new function to cryptoutil.rs that tests a Digest by feeding it 1,000,000 'a's with a varying input size and then checks the result. This is basically the same test that already exists in Sha1, so, I update that test. I also implement new tests using this function for Sha2.

The 8th commit adds new functions to cryptoutil.rs to perform integer additions with overflow checking. These functions are useful for keeping track of the size of the message to be processed by Sha1 and Sha2 since these Digests are only defined for messages under a certain size. I update the Sha2 code to use these functions.

The 9th commit updates the existing Sha1 code to use the new functionality in cryptoutil.rs. Hopefully this is a good example of how the new functionality is generally applicable to more than just Sha2 and can be used by future block based Digest functions.

Outside of the #tests, I also tested the Sha2 and Sha1 implementations by generating a few thousand random inputs of up to 10MB in size, calculated the digests using these implementations and Java's implementations checking to make sure that they agree.

Performance Measurements:

Benchmarks:

Before making any updates, the Sha2 performance was:
```
test sha2::bench::sha256_10 ... bench: 104 ns/iter (+/- 3) = 96 MB/s
test sha2::bench::sha256_1k ... bench: 10476 ns/iter (+/- 918) = 97 MB/s
test sha2::bench::sha256_64k ... bench: 671398 ns/iter (+/- 9934) = 97 MB/s
test sha2::bench::sha512_10 ... bench: 86 ns/iter (+/- 6) = 116 MB/s
test sha2::bench::sha512_1k ... bench: 6114 ns/iter (+/- 50) = 167 MB/s
test sha2::bench::sha512_64k ... bench: 393582 ns/iter (+/- 22549) = 166 MB/s
```
After the changes in change 4, the performance improved to:
```
test sha2::bench::sha256_10 ... bench: 101 ns/iter (+/- 7) = 99 MB/s
test sha2::bench::sha256_1k ... bench: 7736 ns/iter (+/- 177) = 132 MB/s
test sha2::bench::sha256_64k ... bench: 492327 ns/iter (+/- 12650) = 133 MB/s
test sha2::bench::sha512_10 ... bench: 72 ns/iter (+/- 2) = 138 MB/s
test sha2::bench::sha512_1k ... bench: 5004 ns/iter (+/- 935) = 204 MB/s
test sha2::bench::sha512_64k ... bench: 316444 ns/iter (+/- 8554) = 207 MB/s
```
After the rest of the changes (changes after 5 didn't impact performance much, so this is basically the same as the performance after change 5), the performance further improved to:
```
test sha2::bench::sha256_10 ... bench: 91 ns/iter (+/- 1) = 109 MB/s
test sha2::bench::sha256_1k ... bench: 7018 ns/iter (+/- 3036) = 145 MB/s
test sha2::bench::sha256_64k ... bench: 449890 ns/iter (+/- 9512) = 145 MB/s
test sha2::bench::sha512_10 ... bench: 63 ns/iter (+/- 0) = 158 MB/s
test sha2::bench::sha512_1k ... bench: 4052 ns/iter (+/- 1087) = 252 MB/s
test sha2::bench::sha512_64k ... bench: 256686 ns/iter (+/- 1721) = 255 MB/s
```
Before making any updates, the Sha1 performance was:
```
test sha1::bench::sha1_10 ... bench: 85 ns/iter (+/- 6) = 117 MB/s
test sha1::bench::sha1_1k ... bench: 8090 ns/iter (+/- 230) = 126 MB/s
test sha1::bench::sha1_64k ... bench: 523690 ns/iter (+/- 160571) = 125 MB/s
```
After the updates to the Sha1 code, the performance improved to:
```
test sha1::bench::sha1_10 ... bench: 87 ns/iter (+/- 4) = 114 MB/s
test sha1::bench::sha1_1k ... bench: 6221 ns/iter (+/- 61) = 164 MB/s
test sha1::bench::sha1_64k ... bench: 395805 ns/iter (+/- 4292) = 165 MB/s
```

Cycle counts:

Sha512 performance on my machine is: 10.95 cycles / byte. Intel [1], has a Sha512 implementation that achieves 9.4 cycles / byte using the SSE instructions (the AVX implementation is slightly faster, but, only runs on Haswell processors, I think). Assuming that that is the best possible performance, there really isn't all that much more room for optimization without resorting to assembly. I'm not sure what optimized C implementations generally achieve. Prior to the rebase, I was getting about 11.5 cycles / byte. I'm not sure why the performance improved a bit, possibly just variation on my machine or maybe the new code to keep track of the message length is a bit more efficient.

Sha256 performance on my machine is: 18.55 cycles / byte. Intel [2] achieved roughly 13.8 cycles / byte in their single threaded SSE implementation. Like Sha512, I think this puts the Sha256 implementation pretty close to the limit on how efficient it can be without resorting to assembly, though not as close to Sha512. After the rebase, the performance seems to have decreased by about 1 cycle / byte. The only new change was to how the message size is being calculated. I haven't done any testing specifically focusing on that at this time, however.

I used the RDTSC instruction to measure the cycle counts. In my measurements, I took into account the entire digest operation all the way through calculating the output digest. Its a little unclear to me if Intel's measurements were just of the compression function or if they included the output digest calculation steps as well.

I didn't / can't measure performance on non-Intel architectures. However, I don't think that any of the changes I made would result in decreased performance on other architectures. I redid my cycle calculations after the rebase.

[1] - http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/fast-sha512-implementations-ia-processors-paper.html

[2] - http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/sha-256-implementations-paper.html