Add support for 5.4 bivariant type parameters in type declaration

[NathanReb]

This exhibits how I initially envisioned the encoding of bivariant type parameters, or of any other such AST change that cannot directly be encoded into an extension point.

The idea is that the feature is encoded locally at the parameter tuple level (which is already one level up the variance node), and then wrapped into an extension at the closest level, e.g. here, at the structure_item_desc level.

The reason why we don't simply use the parameter encoding is because it can to easily result in ppx-authors misinterpreting it, e.g. they could operate on the variance, ignoring the core_type in the tuple and therefore completely misinterpreting the AST.
We instead ensure that no one inadvertently traverse an encoded node by wrapping the whole structure_item in an extension.

This may seem overkill but protects us against nasty and hard to trace bugs by preventing tempering with encoded data which can lead to migration failure or worse, silent and invalid rewriting of the AST during migration.

The addition of bivariant type parameters makes for one of the worst possible case for our new encoding approach as it spreads quite far up the tree, especially considering it would have been ignored by most ppx-es. We chose the safe approach here, the tradeoff being that ppx won't be able to support bivariant parameters without updating.

The positive here is that this is such a niche feature that most users will never encounter this feature, let alone have it involved with any kind of ppx rewriting, that the encoding should not cause too much trouble in the wild.

Once again, this is still a net positive over the previous situation since old code will always preprocess and compile without troubles.

[NathanReb]

I'm opening a draft PR that only handles bivariant parameters in type declaration, in structures. We still need to add support for them in:

• type_declaration in signature
• type_declaration in module_type_desc
• type_extension
• class_declaration
• class_description
• class_type_declaration

This amounts to writing boilerplate that plugs in the existing encoding/decoding of type parameters and add the right extension point wrapping but is still a significant bit of work for a niche feature.

[NathanReb]

Checking that attributes are [] should be moved to the decode function here so that it leads to an error rather than to let an uninterpreted extension slip through.

I'm also conflicted on whether we should go for this case based approach vs having the decode function simply be something like:

val decode_pstr : loc:Location.t -> structure_item_desc -> structure_item_desc option

Any thoughts @patricoferris ?

[patricoferris]

This looks good to me @NathanReb.

Whilst I'm not stoked about the use of exceptions for non-exceptional control-flow, I think it is worthwhile given how little the migration code tends to move for older compiler versions.

[patricoferris]

Thanks @NathanReb -- I much prefer this implementation over the previous exception and reference based version! Happy for this to go in whenever.

[NathanReb]

I just rebased and will merge once it goes green!