Proto: fix inner global constants

Context

We don't want to allow global constants of the form constant (constant <hash of valid hash>). As long as we disallow this, all constants are "static", meaning we can determine which constants are being used only by traversing the AST of a contract + the AST of any constant references (i.e, no expansion is required). This makes it easier should someone wish to assert a particular (perhaps malicious) constant is not in use.

This happens to true in every practical case already, and thus this MR is not strictly needed for release; however, there is a (degenerate) case where it's possible constants of this form. If you expand a Micheline expression that has the form constant (constant <hash of valid hash>) that is top level (i.e, not wrapped in any other prim or seq), then it works. Practically this is useless because all scripts, etc. are wrapped in Seq. But for the sake of completeness this MR fixes the algorithm to forbid this edge case and adds a unit test asserting so.

Manually testing the MR

(These tests should also work without this MR for reasons explained above)

mockup_client register global constant 999 from bootstrap1 --burn-cap 1
# <hash: expruQN5r2umbZVHy6WynYM8f71F8zS4AERz9bugF8UkPBEqrHLuU8>

 mockup_client register global constant '"expruQN5r2umbZVHy6WynYM8f71F8zS4AERz9bugF8UkPBEqrHLuU8"' from bootstrap1 --burn-cap 1
# <hash: exprvPN8iTQeB64mbDxAEGSNvkrHukcSGRcRavyzUsDgykHgTZB93H>

# this works fine.
mockup_client normalize script 'constant "expruQN5r2umbZVHy6WynYM8f71F8zS4AERz9bugF8UkPBEqrHLuU8"'
# ouptuts { 999 }

# this should not work.
mockup_client normalize script 'constant (constant "exprvPN8iTQeB64mbDxAEGSNvkrHukcSGRcRavyzUsDgykHgTZB93H")'
# Expected output:                          
# Found a badly formed constant expression. The 'constant' primitive must always be followed by a string of the hash of the # # expression it points to.
# Fatal error:
#  ill-typed script

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, the Development Version section of CHANGES.md for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR