Thanks @tjade273!

Also added myself as an author

Should have a working geth precompile and initial benchmarks shortly

While 2046's cheaper precompile contract calls aren't a requirement for
this EIP's implementation, shipping this precompile without EIP-2046
would make the F function expensive for some of the motivating usecases.

Replace the existing ABI encoding interface to the BLAKE2b `F`
precompile with a loosely pack struct that's `staticcall`-friendly.

H/t to @pdyraga for putting together the interface!

Let's not relitigate precompiles, WASM, etc in thie EIP :)

If a conflicting EIP is moving forward the EIP editor can assign a new
address

Contributing docs suggest EIPs be named `eip-draft-with-a-title` until
an editor has been assigned, but discussing this work off-platform
without a number is a problem.

Assigning 152 as the issue number where the `F` precompile was
originally raised (ethereum#152)

Thanks @axic 🙌

- F precompile accepts now `abi.encodePacked` parameters taking 
exactly 213 bytes. This is safer and does not require left-padding data
- `rounds` parameter is now the first one as the gas cost depends only
on this parameter

This rule is compatible with Solidity for boolean.

The specification should not be Solidity-specific. Instead of
referring to abi.encodePacked we now just say "tightly encoded".

"specified in the RFC" linked to the geth PR for F precompile
instead of linking to the BLAKE2b RFC.

BLAKE2b is consistently little-endian. abi.encodePacked encodes each 
of its arguments in big-endian order. We need to be clear which parameters
should go as little-endian (h, m, t) and which parameters should go as 
big-endian (rounds, f).

Test cases covered:
- input length too short
- input length too long
- malformed f flag encoding
- correct input, test vector from BLAKE2b RFC, Appendix A