Protobuf specification rework (#131)

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

.gitignore

@@ -62,3 +62,7 @@ modules/website/static/api
 *.hnir
 
 .bsp
+
+# smithy LSP
+build/smithy
+.smithy.lsp.log

build.sc

@@ -141,6 +141,10 @@ object core extends BaseJavaModule {
   }
 }
 
+object protobuf extends BaseJavaModule {
+
+}
+
 val scalaVersionsMap =
   Map("2.13" -> "2.13.7", "2.12" -> "2.12.17", "3" -> "3.3.0")
 object openapi extends Cross[OpenapiModule](scalaVersionsMap.keys.toList)

docs/protocols/gRPC.md

@@ -6,6 +6,8 @@ The following traits should be taken into consideration by implementors of the p
 
 - alloy.proto#protoIndex
 - alloy.proto#protoNumType
+- alloy.proto#protoWrapped
+- alloy.proto#protoCompactUUID
 
 Additionally, the following traits can be taken into consideration by other tooling to translate smithy specifications to proto specifications.
 

docs/serialisation/json.md

@@ -1,8 +1,8 @@
-### JSON serialisation
+## JSON serialisation
 
 `alloy` defines a number of traits that can be taken into consideration by protocols to express additional constraints and encodings typically found in the industry.
 
-#### Unions
+### Unions
 
 Unions in this protocol can be encoded in three different ways: tagged, discriminated, and untagged.
 
@@ -11,7 +11,7 @@ By default, the specification of the Smithy language hints that the `tagged-unio
 However, `alloy#simpleRestJson` supports two additional encodings: `discriminated` and `untagged`, which users can opt-in via the `alloy#discriminated` and `alloy#untagged` trait, respectively. These are mostly offered as a way to retrofit existing APIs in Smithy.
 
 
-##### Tagged union
+#### Tagged union
 
 This is the default behavior, and happens to visually match how Smithy unions are declared. In this encoding, the union is encoded as a JSON object with a single key-value pair, the key signalling which alternative has been encoded.