Fix: make entity field presence an error

[jmcardon]

In pact 4, defpact steps have a "private entity" optional expression parameter which currently we do not support in pact 5.

Regular defpact steps take 1 argument, if they have a rollback they take 2 args.
There's an "optional" entity argument which, if present, basically causes the defpact to fail 100% of the time.

pact> (module m g (defcap g () true) (defpact f () (step 1 2) (step 1 2)))
"Loaded module m, hash P4sRCOphLqh1gv6h2Vw_WBVDCfRg6iDQJXLvgn0W0QY"
pact> (f)
<interactive>:0:51:Error: applyPact: step entity must be String value
 at <interactive>:0:0: (f)
pact> (module m g (defcap g () true) (defpact f () (step "bob" 2) (step "bob" 2)))
"Loaded module m, hash AJ6muDjYGH0s3GOcfEso3_2wgVM45MIXknuSi9OKqpo"
pact> (f)
<interactive>:0:45:Error: applyPact: private step executed against non-private environment
 at <interactive>:0:0: (f)

Pact 5 was basically simply ignoring the private entity parameter, but parity replay makes it clear that since people made the mistake of deploying contracts where this field is present, it should be a static error. This PR turns this field's presence into an error in two ways:

• If it is found at deploy time (in pact 5), we fail with EntityNotAllowedInDefPact and we do not allow the module to be deployed.
• If It is found at runtime (as will be generally the case with legacy deployed modules), we fail with EntityNotAllowedInDefPact when attempting to execute a step with an entity.

PR checklist:

• Test coverage for the proposed changes
• PR description contains example output from repl interaction or a snippet from unit test output
• (If Relevant) Documentation has been (manually) updated at https://docs.kadena.io/pact

Additionally, please justify why you should or should not do the following:

• Benchmark regressions

• N/A

• Confirm replay/back compat (Ignore until core release)
• (For Kadena engineers) Run integration-tests against a Chainweb built with this version of Pact (Ignore until core release)

[jmcardon]

Note: These are separate cases for a few reasons:

• We don't want to change hashes this close to release, and having new ADT cases ensures our CBOR repr doesn't have to.
• It makes it more explicit to handle cases in functions like hasRollback and ordinaryDefPactStepExec

[emilypi]

This was a vestigial feature of the private blockchain we no longer support. +1 from me.