Yellow paper configuration

[sdcioc]

I have changed the project's architecture to resemble the yellow paper definitions better. This will make the implementation more straightforward to understand.

1. Opcodes: I implemented all the opcodes of the Shanghai version. I divided them between multiple classes as static functions with only the parameters they use in their run. The classes are:
   For alu_operations.cuh : arithmetic_operations (0s: Arithmetic Operations), stack_operations (POP 50: POP, PUSH0 5F: PUSH0, PUSHX 60s & 70s, DUPX 80s, SWAPX 90s), comparison_operations (10s: Comparison Operations), bitwise_operations (10s: Bitwise Logic Operations).
   For env_operations.cuh: block_operations (40s: Block Information), environmental_operations (20s: KECCAK256, 30s: Environmental Information + SELFBALANCE).
   For internal_operations.cuh: internal_operations (50s: Stack, Memory, Storage and Flow Operations).
   For evm.cuh: system_operations (STOP, f0s: System operations).
2. ethtest: Most of the ethtest are passing. There are some errors from static calls, recursive calls, and self-destructs. For the recursive call, there might be a problem with the gas cost of some operations. The way I implemented the operations can make space for better unit testing. I improved our tracer with memory and state status (access/touch) during execution. It will help during our debugging and when we analyse some executions in detail.
3. cmake: I add cmake files for compiling and documentation. The compile cmake file needs to be fixed.
4. documentation: For the documentation, I used Doxygen in a pipeline with Sphinx with the breathe and exhale extensions. Some undocumented functions still exist, and the final structure could look better. I put the entire pipeline in the GitHub action workflow to generate the GitHub page for our project. Currently, the whole process is automatic. We must add some filters or restructure in the pipeline to make the final GitHub page documentation more appealing.
5. performance: The performance could be better for the initial setup and copying back the data to the CPU from the GPU. A difference from the previous implementation is that we can run multiple instances in parallel. We can look at another similar project to compare the benchmarks (https://github.com/primitivefinance/arbiter) or compare with the performance of the revm.

Conclusion: The current PR can be seen as a good base for further improvements:

1. Move the systems_operations to a different file.
2. Make unit testing for operations.
3. Debug and fix the remaining failing tests. @cassc On some tests with a stack overflow/underflow error, there is no trace from the evm-interpreter.
4. Fix the cmake to compile the CUDA code (most probably does not get the C++ flag)
5. Beautify the final documentation.
6. Improve the performance: prefetch the transactions on the GPU, initialise the KECCAK parameters on the GPU, test the performance without the tracer, and improve the transfer from the GPU to the CPU by computing the number of SMs and threads doing the transfer (currently is an instance per SM so it waits for every SM to be allocated on the GPU, we can increase the number of instances per SM)
7. Add the fuzzing implementation @taquangtrung .

[minhhn2910]

Thanks Mr Dan. Let's merge first before we make other PRs. I think we should break long PR to multiple smaller ones in the future.