Protobuf specification rework

[Baccata]

Rework the protobuf specification.

The goal is to allow for more control over what should be wrapped in messages and what should not be wrapped, avoiding implicit rules that prevent sound refactoring/evolutions of smithy specifications.

In particular :

1. addition of a alloy.proto#protoWrapped trait that can be added on simple shapes + lists + maps + members targeting those. This is the only signal allowed for deciding whether something should be wrapped or not.
2. addition of a number of validation rules for smithy shapes that belong to a transitive closure of a gRPC or protoEnabled shape. These rules ported from the proto language, such as (but not limited to) :
   • proto oneof members cannot be repeated/map fields => smithy members of unions targeting map/list shapes MUST have @protoWrapped
   • proto maps cannot have messages => smithy map keys MUST NOT have @protoWrapped
   • when @protoIndex are present on enum/int enum members, one of the value MUST BE 0
   • when @protoIndex is absent on intEnum members, one of its enum values must be 0
   • etc etc
3. created an alloy-protobuf artifact with proto files containing messages that can be used by smithy-translate and other tools to facilitate the abidance to the rules described in the alloy protobuf specification

This PR is to remain a draft until the semantics described in it are incorporated in smithy-translate and validated in some "smithy4s-protobuf" POC

[daddykotex]

smithy translate did that for shapes with the type:alloy#UUID

https://github.com/disneystreaming/smithy-translate/blob/main/modules/proto-examples/protobuf/demo/definitions.proto#L24

[Baccata]

I'm aware. We shouldn't use shapeIds to discriminate behaviour, it's pretty unsound. Using traits is much better.

I guess your point is that we could apply that trait to the alloy#UUID idea to retain the current behaviour.

[lewisjkl]

One potential downside of applying it to alloy#UUID is then the alloy core namespace would depend on the proto one which I'm not sure we want (maybe fine though)

[daddykotex]

I did not know you were aware, I agree with you that the trait is a better approach now that I know better!
But as jeff points out, I don't think introducing a dependency between the two artifacts is desired so I would just leave it like that

[lewisjkl]

One potential downside of applying it to alloy#UUID is then the alloy core namespace would depend on the proto one which I'm not sure we want (maybe fine though)

[daddykotex]

I just realized this test title mentions OpenEnumTrait but it's not used in the code, so either the title is wrong, of the annotation was forgotten on the intEnum member