Proto: deny zero tickets

Fix #3646 (closed)

Context

This MR will enable the interpreter to completely disallow creation, storage or transfer of tickets of zero amount in contract storage, lazy storage or transaction parameters. This will greatly simplify ticket accounting in various contexts.

Impact to originated contracts

Contracts originated no later than Protocol Kathmandu may invoke TICKET instructions. Those instructions will continue to function unless the result will be a ticket with zero amount, in which case a hard error is thrown and the script is rejected. To do so, we first rename this instruction to TICKET_DEPRECATED while maintaining binary stability. Therefore, after this change, when getting script code via RPC calls, the old TICKET instructions will appear as TICKET_DEPRECATED instead. It is not possible to use this instruction in origination in the next protocol because legacy flag is checked and the origination can get rejected if the script contain this deprecated instruction.

Change to newly originated contracts

New contracts needs to be aware of the possibility of failure in ticket creation. The new TICKET instruction will instead wrap the resultant ticket in an option: if a Some value is pushed onto the stack, there is a ticket successfully created and wrapped in the Some; otherwise, it pushes a None and the ticket creation fails.

Tests done

• We have tests to ensure that the said migration of the old TICKET instructions are properly renamed to TICKET_DEPRECATED after activation of the new protocol
• There are tests to ensure that creation of zero ticket leads to script rejection in the old contracts and the new TICKET instruction pushes None onto the stack.

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