Give Rust proto enums name(), from_name() and EnumValueNames, except under Lite.

Every other protobuf language converts an enum value to and from its .proto
name: C++ has `Foo_Name` and `Foo_Parse`, Java `getValueDescriptor().getName()`
and `valueOf`, Python `Name` and `Value`, Go `String()` and `Foo_value`. Rust has
neither. The generator already emits every value name into each binary through
the private `constant_name()` that backs `Debug`, but callers can't reach it,
and it returns the prefix-stripped Rust constant name (`NotFound`) rather than
the .proto name (`STATUS_NOT_FOUND`).

Rust code that has to produce or accept the same strings as other languages
(logs, metric labels, config files, flags, and text formats that carry enum
names) therefore hand-writes a two-way match for each enum, which drifts
whenever a value is added to the .proto file. Generic libraries can't do it at
all, since there is nothing to call through `T: Enum`.

Add `pub const fn name(self) -> Option<&'static str>` and
`pub fn from_name(&str) -> Option<Self>` to the inherent impl generated for each
enum. Both use the .proto names. For an aliased number, `name()` returns the
first declared name, like `EnumDescriptor::FindValueByNumber`, and `from_name()`
accepts every alias. `name()` returns `None` for an unknown value of an open
enum. `name()` is a generated `match` on the number. `from_name()` binary-searches
a `(name, number)` table, aliases included, that the generator sorts by name, as
C++ lite does, so lookups stay O(log n) for large enums; the search is a shared
runtime helper, so each enum only adds its table. Both work the same on the C++
and upb kernels.

Add a `protobuf::EnumValueNames` trait, with `Enum` as its supertrait, that each
such enum implements by forwarding to the inherent functions, so that generic
code bounded by `T: EnumValueNames` can convert any of them without knowing its
type. The trait method isn't `const`, since stable Rust has no `const` trait
methods; the inherent `const fn` remains for constant contexts. Method calls and
`Type::name` paths on a concrete enum resolve to the inherent functions, which
take precedence over the trait's.

Lite and mobile builds must not embed value names, which leak internal
identifiers from shipped binaries (Java on Android has the getter, but
R8/ProGuard flags its use). So, as `HasReflectionSupport()` does for messages,
enums from `optimize_for = LITE_RUNTIME` files, and every enum when the lite
runtime is forced, get neither the functions nor `EnumValueNames`: code that
needs the names fails to compile with them instead of retaining the names.
Keeping the names out of `Enum` itself is what allows this, since every enum
implements `Enum`.

Neither name can collide with a value constant, because those are always
UpperCamelCase; the same reasoning already permits `constant_name()` and
`number()`. Code that calls a user-defined trait method named `name` or
`from_name` on a generated enum would now resolve to the inherent method.

`enum_test` covers the functions and `EnumValueNames`, including every name of
an enum whose names are declared out of order, and skips them when the lite
runtime is forced. The new `lite_enum_test`, on both kernels, checks that an
`optimize_for = LITE_RUNTIME` enum doesn't implement `EnumValueNames`, and that
other enums do unless the lite runtime is forced.

PiperOrigin-RevId: 996243501