consensus/ethash: implement faster difficulty calculators

[holiman]

This PR is very safe, and doesn't actually do anything.
While I was investigating header import (https://github.com/holiman/headerimport/blob/main/README.md ) , I noticed that there is a lot of time spent (allocations spent) on calculating the difficulty.
This PR adds re-written difficulty calculators, which are based on uint256. It also adds a fuzzer + oss-fuzz integration for the new fuzzer. It does differential fuzzing between the new and old calculators.

Note: this PR does not actually enable the new calculators.
Anyway, if travis looks green, we could merge this and have it fuzzed, and later decide whether about enabling it.

Oh, and there are some benchmarks too, u256-xx are the new ones, big-xx are the old:

BenchmarkDifficultyCalculator
BenchmarkDifficultyCalculator/big-frontier
BenchmarkDifficultyCalculator/big-frontier-6         	 1484992	       722 ns/op	     280 B/op	      12 allocs/op
BenchmarkDifficultyCalculator/u256-frontier
BenchmarkDifficultyCalculator/u256-frontier-6        	 8540350	       176 ns/op	      64 B/op	       2 allocs/op
BenchmarkDifficultyCalculator/big-homestead
BenchmarkDifficultyCalculator/big-homestead-6        	 1506804	       831 ns/op	     288 B/op	      13 allocs/op
BenchmarkDifficultyCalculator/u256-homestead
BenchmarkDifficultyCalculator/u256-homestead-6       	 9134642	       184 ns/op	      64 B/op	       2 allocs/op
BenchmarkDifficultyCalculator/big-generic
BenchmarkDifficultyCalculator/big-generic-6          	 2789331	       387 ns/op	      80 B/op	       7 allocs/op
BenchmarkDifficultyCalculator/u256-generic
BenchmarkDifficultyCalculator/u256-generic-6         	 7718224	       154 ns/op	      64 B/op	       2 allocs/op
PASS

[holiman]

Tested this on bigendian too

[user@work ethash]$ GOARCH=ppc64 go test -c
[user@work ethash]$ qemu-ppc64-static ethash.test -test.v

Works fine

[MariusVanDerWijden]

LGTM (I mainly looked at the fuzzers though)

[MariusVanDerWijden]

Just thinking out loud, if we moved the formula from max(1 - (block_timestamp - parent_timestamp) // 10, -99) to max((time - ptime) / 10 - 1, 99) this should become min right? e.g. min((time - ptime) / 10 - 1, 99)

[holiman]

Right, so what we want is the absolute value to not exceed 99. So hence the if x>=100 above.