Plugin: add RPC and client command to run contract views

Context

This MR implements an RPC to call views from contracts (and a corresponding client command) to avoid relying on scripting it with run script. This is a similar mechanism as introduced for TZIP4 views: a script is forged specifically to call the view with the given input and store the result in its storage. The storage is then returned as is.

The last commit adds an option to run views with unlimited gas (some contracts might have such unusable views onchain only for indexers to extract infos), which is set to false by default. This unlimited gas is implemented using the hard limit from Saturation_repr (basically max_int), since the interpret doesn't take account of the native unlimited mode (see note !4034 (comment 774734253))

User experience discussion: TZIP4 views vs native views

This MR is opened to discussion as there are some UX issues to solve:

• /helpers/run_view corresponds to already existing TZIP4 views RPC
• /helpers/run_script_view corresponds to the contract view RPC currently added

Both have almost the same interface (one expect an entrypoint name, the other a view name, and the rest are identical), but I chose to keep the two RPCs separate instead of trying to merge them, and possibly in the future rename run_view into run_tzip4_view for consistency (and deprecate run_view).

Manually testing the MR

You need a contract with views, the one given in the documentation is a good example:

tezos-client originate contract viewable transferring 0 from bootstrap1 running '{ parameter nat; storage nat; code { CAR; NIL operation ; PAIR }; view "add_v" nat nat { UNPAIR; ADD }; view "mul_v" nat nat { UNPAIR; MUL }; }' --init '10' --burn-cap 0.10

then you can simply call the views with:

tezos-client run view add_v on contract viewable with input "10"

which should yield 20, since the contract has been initialized with 10, and the view add_v returns storage + input

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