feat(AIP-191): add go_package guidance (#1371)

Author: noahdietz

aip/general/0191.md

@@ -118,9 +118,24 @@ When defining APIs, the following rules apply:
     option php_namespace = "Google\\Cloud\\AccessApproval\\V1";
     option ruby_package = "Google::Cloud::AccessApproval::V1";
     ```
+  - The `go_package` value depends directly on how the Go code is managed i.e.
+    if the module name is based on the VCS provider or using a remote import
+    path, but often has a consistent structure.
+    - The module **may** differ based on product area e.g.
+      `google.cloud.accessapproval.v1` would be in module
+      `cloud.google.com/go/accessapproval`.
+    - The package import path **should** be derived from the proto package.
+    - An API version in the proto package **should** be prefixed with `api` e.g.
+      the proto package segment `v1` becomes `apiv1`.
+    - The terminal import path segment **should** be based on the product name
+      found within the proto package and **must** be suffixed with `pb` e.g.
+      `accessapproval` becomes `accessapprovalpb`.
+    - This value **should** be left to the team owning the generated code to
+      decide on.
 
 All packaging annotations **should** be specified in alphabetical order of
-name.
+name. Refer to the [Protobuf documentation][package docs] for more about
+language package options.
 
 **Important:** While languages other than Java have sensible defaults for APIs
 which don't include compound names, be aware that _adding_ this annotation
@@ -138,9 +153,22 @@ required in combination with `java_multiple_files`. It instructs `protoc` to
 wrap each compiled Protobuf type in a Java class whose name is the value of the
 option. This prevents potential naming collisions between generated types.
 
+
+### Go packaging option
+
+The Go packaging option needs to be decided by the team that owns the generated
+code, because it is directly tied to the source code management practices of the
+team. Allowing every proto package to decide on their own Go package creates
+inconsistencies and friction in management of the code. Within that owning team,
+having a consistent structure in the Go package naming is critical to a 
+consistent end user experience.
+
 ## Changelog
 
+- **2024-06-13**: Added guidance for Go packaging annotation.
 - **2024-06-05**: Added rationale for Java packaging options.
 - **2023-02-24**: Added guidance on protobuf syntax.
 - **2022-10-18**: Added guidance on Ruby/PHP/C# options.
 - **2019-11-18**: Added guidance on the packaging annotations.
+
+[package docs]: https://protobuf.dev/programming-guides/proto3/#packages