Set default_api_level=API_HYBRID for protobuf-go v1.36.0

[bufdev]

Open questions:

• Does a new revision get automatically created for v1.36.0?
• Should we delete the protoopaque files by wrapping protoc-gen-go and deleting them from the resulting CodeGeneratorResponse on the fly? I'd argue no, as while the build tag logic isn't our favorite, that's just our opinion, and we should match protoc-gen-go behavior unless there's a strong reason not to.

[bufdev]

You could actually argue that we shouldn’t make this the default for remote plugins, but should for generated SDKs, so we may want to close this PR in the. end.

[mfridman]

Yes, we'll get a revision bump and subsequent go get ... requests will generate hybrid (opaque+open) code.

I don't think we want to modify the response because there might be some users who explicitly want this. Also, we probably don't want to couple the generator output too closely with the implementation of Generated SDKs or deviate too much from the default behavior of protoc-gen-go.

If we were to go down this route, we'd be better off applying a patch to exclude those files from being generated in the first place. We have some prior art for git-based patches and custom builds.

We're in a predicament of having to pick exactly one sane default. Although I think default_api_level=API_HYBRID is the least-worst option because it satisfies the most amount of use cases, including the new OPAQUE API, which was not previously possible without .proto changes (which we actively discourage).

Unless @pkwarren @stefanvanburen have any objections I think we should roll forward with this.

[mfridman]

I wonder if we should also bump grpc/go to depend on the updated protocolbuffers/go version?