## Description 

When introducing u16, u32, u256 a while back, I noticed it was possible
to break multiple dependent systems if some enums were modified out of
order.
So I put a comment to warn folks
```
    // NOTE: Added in bytecode version v6, do not reorder!
```
This PR now adds a test which ensures that new enum variants are
appended in a backward-compat manner
Sample output:
```
panicked at 'Enum variant Address has been swapped with AddressNew at position 3. Not allowed: enum must be backward compatible.'
```
Usage:
`#[test_variant_order(path/to/snapshot/file.yaml)]`



## Test Plan 

How did you test the new or updated feature?

---
If your changes are not user-facing and not a breaking change, you can
skip the following section. Otherwise, please indicate what changed, and
then add to the Release Notes section as highlighted during the release
process.

### Type of Change (Check all that apply)

- [ ] user-visible impact
- [ ] breaking change for a client SDKs
- [ ] breaking change for FNs (FN binary must upgrade)
- [ ] breaking change for validators or node operators (must upgrade
binaries)
- [ ] breaking change for on-chain data layout
- [ ] necessitate either a data wipe or data migration

### Release notes