Precompiles tests

[mrLSD]

This discussion is related to #307 issue. After the investigation, it was created branch: https://github.com/aurora-is-near/aurora-engine/tree/tests/precompiles

Also was created PR: #348 - but we decided to close it because the main goal was to investigate what was exactly is wrong with precompiles tests.

The main goal is to run evm state tests: https://github.com/ethereum/tests/

As a library was decided to use SputnikVM evm-tests: https://github.com/rust-blockchain/evm-tests
However, the library was designed in such a way that it cannot be imported.

For research purposes only, some of the library modules have been ported into our tests.

Actually, it does not follow Engine code quality standards. Since the main goal is to research the presence or absence of problems with precompiles.

What results have we arrived at:

• To initialize the state, we used MemoryBackend with engine-precompiles
• The vast majority of precompiled tests run successfully, but there are also errors

Running blake2B:Berlin:10 ... thread '<unnamed>' panicked at 'index out of bounds: the len is 12 but the index is 12', /home/pc/.cargo/git/checkouts/near-blake2-68f547953c312965/736ff60/src/blake2b.rs:4:1
thread 'tests::eth::state::st_precompiled_contracts' panicked at 'called `Result::unwrap()` on an `Err` value: Any { .. }', engine-tests/src/tests/eth/state.rs:223:18

and Hash not equal assertion fails.

The essence of this discussion is to come to a decision - whether these rare errors of passing precompile tests are critical or significant for Engine. Also decide what we should do next with that.

[birchmd]

the main goal is to research the presence or absence of problems with precompiles

I think this should not have been the main goal of this work. We had a bug report from what looked to me like a trustworthy source, so I did not have any question in my mind that there are bugs in the current precompiles. Whether or not they are critical is another question, but either way we must fix them to have 100% Ethereum compatibility.

The main goal should be to write code that does meet our quality standards so that it can be merged into the codebase. This will not only reveal the current bugs, but also prevent us from introducing new bugs in the future. Using the Ethereum json tests also means we will get new tests with each hardfork upgrade, which is another important reason to do this work properly.