Profiling ppx: Replace all profiler calls with a ppx

What

Create a ppx that allows to call the Profiler or not depending on an environment variable.

• The profiler linking is done at compile time (currently with TEZOS_PPX_PROFILER=anything)
• The profiler execution is done at execution time (with PROFILING=detailed)

Why

To profile Tezos, a parallel branch was created and rebased on master regularly. This is hard to maintain and takes a lot of time.

The reason why this code is not in master is because it creates indirections and may slow down octez even if the profiling is not activated.

How

This MR aims to replace all the calls to profiler in this branch with a ppx that will be transformed only if the TEZOS_PPX_PROFILER environment variable is not empty.

The MR cherry-picks some commits from the previous branch but most of them will be removed once it is clear that it does the same thing as before. Cherry-picking these commits may help reviewing the code to check that the ppx is applied to the proper expression.

Manually testing the MR

• TEZOS_PPX_PROFILER=profiling make then ocamlc -dsource _build/default/src/lib_shell/prevalidator.pp.ml to see that the ppxes have been transformed
• make then ocamlc -dsource _build/default/src/lib_shell/prevalidator.pp.ml to see that the ppxes have been untouched
• If you built octez with TEZOS_PPX_PROFILER=something you can now check that it generates profiling files by doing

  PROFILING=detailed ./octez-node run --data-dir <your/data/dir>

• In your/data/dir you should see

  /your/data/dir
  ├── block_validator_profiling.txt
  ├── chain_validator_profiling.txt
  ├── config.json
  ├── ...
  ├── store_profiling.txt
  └── version.json

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• 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