The "standard imports" (made available to compile operations using
`protocompile.WithStandardImports`) are files that would be included
with `protoc`, if a user were instead compiling with `protoc`.

As of v26.1, `protoc` now includes two new files:
"goole/protobuf/cpp_features.proto" and
"google/protobuf/java_features.proto". But these are _not_ generated to
Go code into packages in the Protobuf runtime, unlike all of the other
well-known imports. So, for these, we embed binary-encoded file
descriptors.

Notably `protoc` does **not** include
"google/protobuf/go_features.proto". However, that file _is_ part of the
Go Protobuf runtime, with its generated code being available via the
`google.golang.org/protobuf/types/gofeaturespb` package. So we also make
that file available via `protocompile.WithStandardImports` (even though
`protoc` doesn't include it).

…nal/benchmarks (#293)

…lation results (#302)

This verifies that the results of compilation are processable by
`protodesc.NewFile`. There's an opt-out for cases where we know the
protobuf-go runtime can't correctly handle it.

…the range is verified (#303)

I didn't quite implement this correctly, where "correct" means matching
the behavior of `protoc`. For `protoc`, the presence of a declaration
_implies_ that `verification = DECLARATION`.

https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/descriptor.cc#L8003-L8023

I previously had implemented it where validation only occurred when
`verification` was _explicitly_ set to `DECLARATION`. Oops.

…#296)

…lable to users (#301)

This updates to protobuf-go v1.34.1, which provides the latest
`descriptor.proto` updates in its `descriptorpb` package. With that, we
are able to implement the final change before allowing end-users to use
protocompile with editions: enforcing feature lifetimes.

So this PR implements that last change and also makes Editions
generally available: it's no longer disabled-by-default, requiring
opt-in via "testing" method.

The last change is a check to verify that a feature isn't being used outside
its expected lifetime. This PR also adds an exported helper to the root
protocompile package: IsEditionSupported. This advertises to consumers
of the package which editions it can compile.

This makes sure that declarations are enforced, even when no
declarations are present, as long as `verification` is explicitly set to
`DECLARATION`.

…or (#305)

…tom feature (#306)

Previously, the protoutil.ResolveCustomFeature code was unable to
reliably handle the following case:
1. The descriptor includes dynamic extensions for all custom options and
custom features.
2. The user supplies a _generated_ extension type, to query for the
custom feature.

The code here _ostensibly_ handles this. But the cases where it decides
it needs to adapt the value (by marshalling and then unmarshalling into
different type) isn't quite thorough enough. The issue is when the
custom feature is a _message_. In that case, it works fine to query for
the extension itself. But if we then need to extract a field from the
message, the field descriptor is likely referring to a generated message
type, whose descriptor is an instance in `protoregistry.GlobalTypes`.
But the value is likely to be a dynamic message, whose descriptor may
have been constructed dynamically (such as being parsed from source). In
that case, the `protoreflect` stuff will happily panic when it sees the
mismatch 😱.

This commit fixes this issue so that custom feature values can be
successfully queried under these conditions, without panic.

…l v27.0 (#309)

This change mirrors two of the changes in the final v27.0 of protoc
that were not previously implemented in this compiler:

1. A new `feature_support` field on `EnumValueOptions` to allow defining
the lifetime of a feature value. This is similar to the field of the
same name and type on `FieldOptions`, but it controls the actual enum
values and in which editions they are valid.
2. A new check that a feature is not used from the same file in which
it's defined.

This change updates this repo to use the latest (final) v27.0 release and
also updates the protobuf-go dependency to include the v27.0 version
of the `descriptorpb` package.

…e standard imports (#310)

This adds wellknownimports.WithStandardImports as an alternative
to protocompile.WithStandardImports. The alternative provides
source code for the imports instead of just providing the embedded
descriptors from generated Go code. This allows users to make use
of the extension declarations added to `descriptor.proto` in v27.0
(they are absent from embedded descriptors since they are marked
as source-only retention).

…312)