refactor(wasm-gen, runtime-fuzzer): Increase successful messages execution rate in runtime-fuzzer.

[techraed]

This task was a hot one from the beginning of runtime-fuzzer launch when first production coverages were available. The issue was that there were too many traps, which caused a very weak coverage for messaging logic in the pallet_gear.

After researching it thoroughly, I have found out that there were 2 many trap reasons: Possibly 'unreachable' instruction reached and Not enough gas to continue execution.
The former trap reason was caused not only by unreachable instruction occurrences, but there were some other internal wasmi errors causing that termination reason. I have turned off unreachable instructions here #3307.
The latter one was mainly due to large loops in wasm - each function body consisted of about 100_000 instructions and these instructions could call other functions with the same size in a loop. Turning off Control instructions can be a solution to that, but it brings some other problems described here #3382. This seems to be the best solution to the problem - #3313.

Basically, there are 3 available params that have a significant effect on execution:

1. Turning off Control (if, loop, try, catch and etc.) instructions. This makes the execution of the ~8gb corpus directory really fast (3 minutes), there are no Not enough gas to continue execution errors, but it there is a still a huge number of traps.
2. Instructions number in the function body.
3. Amount of internal functions generated by wasm-smith.

After running 2 corpuses sets each about 8 gb with different values for these params, I have found out that amount of instructions doesn't have a huge effect on execution time or execution results. In theory, less instructions make less gas errors and more frequent syscalls invocations. In practice, this has a very weak effect when amount of functions is large. The third param caused the most effect on increasing the corpus execution speed and amount of successfull executions. Even if there are 100_000 instructions, but less functions, it empirically shows great results.

[techraed]

DON'T MERGE, some performance checks are running

[techraed]

This task was a hot one from the beginning of runtime-fuzzer launch when first production coverages were available. The issue was that there were too many traps, which caused a very weak coverage for messaging logic in the pallet_gear.

After researching it thoroughly, I have found out that there were 2 many trap reasons: Possibly 'unreachable' instruction reached and Not enough gas to continue execution. The former trap reason was caused not only by unreachable instruction occurrences, but there were some other internal wasmi errors causing that termination reason. I have turned off unreachable instructions here #3307. The latter one was mainly due to large loops in wasm - each function body consisted of about 100_000 instructions and these instructions could call other functions with the same size in a loop. Turning off Control instructions can be a solution to that, but it brings some other problems described here #3382. This seems to be the best solution to the problem - #3313.

Basically, there are 3 available params that have a significant effect on execution:

1. Turning off Control (if, loop, try, catch and etc.) instructions. This makes the execution of the ~8gb corpus directory really fast (3 minutes), there are no Not enough gas to continue execution errors, but it there is a still a huge number of traps.
2. Instructions number in the function body.
3. Amount of internal functions generated by wasm-smith.

After running 2 corpuses sets each about 8 gb with different values for these params, I have found out that amount of instructions doesn't have a huge effect on execution time or execution results. In theory, less instructions make less gas errors and more frequent syscalls invocations. In practice, this has a very weak effect when amount of functions is large. The third param caused the most effect on increasing the corpus execution speed and amount of successfull executions. Even if there are 100_000 instructions, but less functions, it empirically shows great results.

After additional performance checks it occurred that changing amount of functions and lowering instructions doesn't actually give much improvement to successful execution rate. Anyway the PR will be merged as it brings some execution improvements (speed).