Tezt: clean up and add tests on the run_operation RPC

Context

This MR reworks existing tests, and adds new tests about the run_operation RPC:

POST /chains/<chain>/blocks/<block>/helpers/scripts/run_operation

The goal is to prepare for changes to this RPC in !5707 (merged) and !5770 (merged), and maybe further reworks in the context of the %(OKR 2022Q3 - 1.1) Pipelining project.

These tests are far from exhaustive, but fully covering run_operation would be very time consuming. Here is a quick explanation of the choice of new tests in this MR:

• The inconsistent counter and bad reveals tests have been added because some batch sanity properties, such as counter consistency and revelation position, are checked separately from individual operation checks in Validate_operation. Therefore, there is a slight risk to forget to check these properties in a future refactoring of run_operation (batches with multiple sources were accepted before K for a similar reason; this is covered by the reworked inconsistent sources tests). Both tests also check some other properties that are not particularly likely to fail, but are close thematically and easy to check.

• correct batch and misc manager ops from fresh account are positive tests that were added because they are easy to write using the tools available in tezt/lib_tezos/operation_core.mli.

• misc manager ops from fresh account also ensures that the effects of operations that belong to the <block> in the RPC's call, have been taken into account in the context in which the given operation is run. Indeed, here we run other manager operations directly on the block containing the manager's public key revelation. This was not completely a given, considering that the RPC weirdly sets the context's current level to <block>'s level rather than its successor (see #3364).

Manually testing the MR

All the reworked and new tests have the run_operation tag:

dune exec tezt/tests/main.exe -- run_operation

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• [N/A] Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• [N/A] For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR