sha256 x86_64 optimization v2

This is a revision of https://github.com/zfsonlinux/zfs/pull/2332

Currently, the optimization only applies to kernel space,
because I haven't figured out how to it properly in user space.

AVX2 is untested because I don't have such CPU.
So use it with you own discretion.
Incorrect checksum calculations caused by a failure in these routines could be extremely damaging to ZFS. The current generic routine lacks a self-check and introducing one is an excellent idea. It is important to understand that the generic routine is restricted to a subset of instructions that operate on the normal integer registers, such that the likelihood of a defect that only affects checksums is small, which allowed us to avoid using a self check in the past. Introducing optimized assembly changes things because we begin exercising transistors that often go unused during normal operation. This dramatically increases the risk of a CPU defect affecting the checksum routines. Having a self test occur only during debug builds means that the vast majority of ZoL installations will have nothing to guard against such defects. At the same time, using preprogrammed data to do a comparison risks passing CPUs with hypothetical defects that affect only some byte sequences and not others.

With those things in mind, I would like to see some changes:

1. A self test should be done whenever we use optimized assembly. This includes non-debug builds. Running this when we use non-optimized assembly in debug builds as you do here should also be done.
2. When we detect that we can use the optimized assembly routine, we should perform a second self-check routine that initializes a bufffer with random data, calculates the hash with the generic routine, calculates the hash with the optimized routine, and compares the result. This is intended to provide some protection against defects that would get past a static input.
3. We need to do an Illumos-style xcall to run this check on all available CPU cores. We could be running on a system where all but 1 CPU core is good, so only checking 1 core like we do here would miss it. We would want to implement the xcall infrastructure in the SPL using Linux's `on_each_cpu()` routine. Code operating in that context will operate with interrupts disabled, so there is no risk of being rescheduled (and failing to test CPU cores) like we have here.
4. There exist Linux systems that support hotpluggable CPUs, so we should detect the addition of CPU cores to a system so that we can test them. I do not know how to do this offhand, so it needs investigation.