delete upb_EnumDef_IsSorted()
We now have a simple internal function for returning a mini descriptor directly from an enum def.
PiperOrigin-RevId: 461208352
1. upb now tolerates a present-but-empty package name in a `FileDescriptorProto`.
2. upb now always returns a non-NULL string for `upb_FileDef_Package()`. If the package was empty or missing, the returned string is zero-length. This better matches the proto2 behavior: `proto2::FileDescriptor::package()` always returns a package string, which may be empty.
PiperOrigin-RevId: 460831797
An enum MiniDescriptor simply encodes a set of valid `int32_t` values, so that the protobuf parser can test whether a given enum value is known or not.
The format implemented here is novel and needs to be documented. In short, the format is:
1. base92 values 0-31: 5-bit mask indicating presence or absence of the next five enum values.
2. base92 values 60-91: varint indicating skip over a region of enum values.
Negative enum values are encoded as their `uint32_t` equivalent.
PiperOrigin-RevId: 442892799
This makes extension checking more strict in most cases.
However it also fixes a bug with MessageSet where we were being
too strict. MessageSet allows larger extension numbers than
normal extensions do.
In a big-endian system, the 64-bit value of 1 is represented as:
```
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x1
```
However, when `d.int32_val` is used, this truncates this and takes the
first four bytes:
```
0x0 0x0 0x0 0x0
```
As a result, we lose the value of 1 from this truncation and the value
beocmes 0. This doesn't happen in a little-endian system because the 1
is in the lowest memory address, so truncating the value to 32 bits
doesn't change anything.
Previously the DefToProto test was failing on a big-endian system
because this truncation caused the key to be incorrectly set to 0.
We now use the type-specific functions
(e.g. `upb_fielddef_defaultint32`) to do this conversion.
Closes https://github.com/protocolbuffers/upb/issues/442