[Proposal] Make opcode enums non-exhaustive

[kaimast]

Whenever opcode enums change, we will get semver errors like the following:

Description:
A public enum's exhaustive unit variant has changed to a different kind of enum variant, breaking possible instantiations and patterns.
        ref: https://doc.rust-lang.org/reference/items/enumerations.html
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.43.0/src/lints/enum_unit_variant_changed_kind.ron

I propose we annotate each opcode-related enum with #[non_exhaustive], so adding new opcodes will not be considered API breakage.

Note, that this change itself would be considered breaking, as code that uses such enums would now be required to include a wildcard (_) in match statements.

[kaimast]

The same should be done for consensus versions:

--- failure enum_variant_added: enum variant added on exhaustive enum ---

Description:
A publicly-visible enum without #[non_exhaustive] has a new variant.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#enum-variant-new
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.43.0/src/lints/enum_variant_added.ron

Failed in:
  variant ConsensusVersion:V12 in /home/circleci/project/console/network/src/consensus_heights.rs:49
  variant ConsensusVersion:V12 in /home/circleci/project/console/network/src/consensus_heights.rs:49

[vicsn]

Nice idea.

I think it's problematic that the compiler won't be able to warn about using all enum components exhaustively anymore.

Also its a bit of an uphill battle trying to prevent reporting of breaking changes - though I agree these commonly changing enums would be nice to cover.

[kaimast]

There's a proposed Rust feature that lets you address that #[deny(non_exhaustive_omitted_patterns)]. Maybe we can revisit this proposal when that feature makes it into stable Rust.