Ensure encodings aren't inadvertently tempered with

[NathanReb]

No description provided.

[NathanReb]

I started this PR with the intent of making sure that:

1. Encodings do not trigger extension checks
2. Traversal classes based rewriters would not temper with encodings inadvertently

1 is already the case but now we have a test for this!

2 I think should be debated before proceeding further. Initially I wanted to overwrite the extension method of all Ast_traverse classes so that they do not traverse the payload of ppxlib.migration extensions by default but there are a few issues with that.

For starters, the traversal classes have no such restrictions at the moment and it's already possible to inadvertently temper or with important bits of the AST by being too aggressive in the rewriting, for instance rewriting payloads of ocaml, merlin or other such attributes or extensions without us trying to prevent it.

If we decide to do it, should we do it for all traversal classes? Only map-like classes? Since we only care about someone altering an encoding in a way that breaks the roundtrip here, that could make sense.

Another approach would be to decode the node, traverse its "valid" children, i.e. ones that are children of the original, non encoded node that are simply copied into the encoding and re-encode the result. Example:

(~a: x, ~b: y)

is encoded as:

[%ppxlib.migration.pexp_labeled_tuple_5_4 (((`Some `a), x), ((`Some `b), y))]

Here we could make it recurse into x and y but preserve the wrapping tuples and the weird polymorphic variant encodings of the labels.
Note that this approach is only feasable for nodes for which we provide the Ast_builder/Ast_pattern interface and that have the 5.2 decoding function.

@patricoferris what do you think?