Proto: Bump the tick limit of the WASM PVM to 50T

This change affect two components:

  - New rollups originated after this patch takes effect will have the new
    limit stored in their state
  - The refutation game will start to target mutiple of 50T instead of 11B to
    ensure the fast execution is being used as long as possible.

As a reminder, the WASM PVM ticks limit was initially introduced as a way to
constrain rollup execution time, in particular when run by the WASM interpreter
of the WASM PVM (which is infamously slow).

The constant of 11B was choosen because, according to our experiments, the WASM
interpreter of the WASM PVM takes around 1h to run this many ticks in on a
developer machine.

Though motivated by legitimate concerns, this choice turned out to be
particularly harmful for honest kernel developers, because the interpreter they
are using to operate their rollup (based on WASMER) is not capable of counting
ticks. For Etherlink, it meant it was necessary to develop a full ticks model
for EVM execution, to ensure the kernel of Etherlink would not exceed its ticks
budget. A painful and uncertain endeavor.

In the end, kernel developers are responsible to ensure their kernel is
refutable, but the “protection” we added to the WASM PVM put them in a
dangerous position, where attackers have an additional attack vector (their
ticks model) at their disposal.

With this change to bump the ticks limit to 50 trillion, we virtually remove
the responsibility of the WASM PVM to ensure the refutability of the rollups
originated on Tezos. On the contrary, we fully entrust this responsibility to
kernel developers. Obviously, kernel developers need to correctly understand
this new responsibility. Actually consuming the 50,000T ticks available every
Tezos level (every 10s with Paris) is most certainly impossible with current
hardware, and would put them at odds to actually protect honest commitments
even if they were able to compute them.

Manually testing the MR

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