Order oneof union members from largest to smallest

Certain compilers (e.g. [0]) incorrectly generate warning messages
when the universal zero initializer is used by the protobuf-c generated
code to initialize a protobuf object containing a oneof that contains a
ProtobufCBinaryData field as the first member. This is now much more
likely due to the change in the previous commit ("protoc-c: c_message:
Order oneof union members from largest to smallest") which will now
always cause a ProtobufCBinaryData field to be placed as the first
member of the union, if one is present in the oneof.

In this situation, we need to add an extraneous pair of braces around
the universal zero initializer in the generated initialization code.

The former behavior of using the universal zero initializer by itself is
kept for oneof unions that do not contain a ProtobufCBinaryData member.

[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80454

This commit changes the code generator to output the members of a oneof
union from largest to smallest, rather than in field descriptor order.

This is necessary on certain compilers such as gcc >= 15 which do not
guarantee that initializing a union with the universal zero initializer
actually initializes all the bits of the object representation of the
members of the union, unless the largest union member is the first
member of the union.

This currently fails on gcc 15 but succeeds on gcc 14, as expected.

build.yml: Ubuntu: Add 22.04, 24.04

- Add Ubuntu 22.04, 24.04 to the standard distcheck job.
- Add Ubuntu 22.04, 24.04 to the CMake job.
- Convert Valgrind job from Ubuntu 20.04 to 24.04.
- Convert coverage job from Ubuntu 20.04 to 24.04.
- Convert the run-on-arch-action job to run on Ubuntu 24.04 (base) and
Ubuntu 22.04 (the arch-specific actions; Ubuntu 24.04 not available).
- Add riscv64 to the list of architectures for the run-on-arch-action
job to run on.

build.yml: Update Windows dependencies (abseil, protobuf)

This flag is not used by the protobuf build system:

    CMake Warning:
      Manually-specified variables were not used by the project:

        ABSL_PROPAGATE_CXX_STD

The static library builds on Windows are throwing obscure linker errors,
but the shared library builds are succeeding, so turn off the static
library builds for now.

Microsoft refuses to ship Ninja in the Windows image so a third-party
script is needed.

build.yml: Try setting -DCMAKE_MSVC_RUNTIME_LIBRARY for abseil, protobuf, protobuf-c builds on Windows

Not sure why we want to cache and suppress the abseil/protobuf builds on
Windows since those are the things that break most often and we should
be alerted when they start breaking.

It looks like this got missed in 4cb63c20.

For MSVC:

- Updated abseil from 20230802.0 to 20240722.0.
- Updated protobuf from 24.3 to 29.3.
- Dropped utf8_range since this appears to have been incorporated into protobuf.

Clean CMake

Chase compatibility issues with Google protobuf >= 26.0

build.yml: Build on more pull request activity types

The default is to build on pull request activity types opened, reopened,
and synchronize. Also build on activity types edited, ready_for_review,
and review_requested.

As detailed in https://github.com/protobuf-c/protobuf-c/pull/711, the
protobuf compiler apparently polices the values reported by a code
generator's GetMinimumEdition() / GetMaximumEdition() methods, if
GetSupportedFeatures() reports that it reports editions.

Returning `FEATURE_SUPPORTS_EDITIONS` broke the legacy `protoc-c`
command-line binary because that binary "registers" the protobuf-c code
generator as a built-in code generator, whereas `protoc-gen-c` (aka
`protoc --c_out=`) is a code generator plugin and the policing performed
by protobuf's `CommandLineInterface::SetupFeatureResolution()` method
apparently doesn't apply to plugins.

This commit prevents our min/max editions from being policed when
invoked as `protoc-c`.

Tested with protobuf 29.3.

The Google protobuf project is currently experimenting with a new syntax
for .proto files called "editions". Since protobuf-c is a proto2/proto3
compiler, after the previous commit reimplementing `FieldSyntax()`, the
protobuf compiler will abort like this if presented with an "editions"
syntax .proto file due to the safety check in `FieldSyntax()`:

    $ protoc --experimental_editions --c_out=. test.proto
    protoc-gen-c: ./protoc-c/c_helpers.h:178: int google::protobuf::compiler::c::FieldSyntax(const google::protobuf::FieldDescriptor*): Assertion `syntax == "proto2" || syntax == "proto3"' failed.
    --c_out: protoc-gen-c: Plugin killed by signal 6.

On protobuf 26, our `CodeGenerator` can implement certain methods to
declare that we "support" editions, and then reject any other edition
except proto2 and proto3, which have apparently been retroactively
declared to be "editions". Of course this needs to be wrapped in a
version guard.

With this protection in place, the protobuf compiler cleanly exits with
a nice error message like this:

    $ protoc --experimental_editions --c_out=. test.proto
    WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
    E0000 00:00:1710988958.296200   20022 descriptor.cc:4620] Invalid proto descriptor for file "test.proto":
    E0000 00:00:1710988958.296239   20022 descriptor.cc:4623]   test.proto: Edition 2023 is later than the maximum supported edition PROTO3
    --c_out: protoc-gen-c: Plugin failed with status code 1.

Recent versions of Google protobuf have broken the interfaces for
determining the syntax version of a .proto file. The current protobuf-c
1.5.0 release does not compile with Google protobuf 26.0 due to the most
recentage breakage. There is a possible workaround involving the Google
protobuf `FileDescriptorLegacy` class, which is documented as:

// TODO Remove this deprecated API entirely.

So we probably shouldn't rely on it.

Instead, this commit obtains the `FileDescriptorProto` corresponding
to the passed in `FieldDescriptor` and interrogates the `syntax` field
directly. This is a single implementation with no version-specific
workarounds. Hopefully this won't break in the next Google protobuf
release.

I tested the `FieldSyntax()` implementation in this commit across a
number of different Google protobuf releases and found that it worked
(`make && make check`) on all of them:

- Google protobuf 3.6.1.3 (Ubuntu 20.04)
- Google protobuf 3.12.4 (Ubuntu 22.04)
- Google protobuf 3.21.12 (Debian 12 + Debian unstable)
- Google protobuf 3.25.2 (Debian experimental)
- Google protobuf 26.1-dev

Previously, we were conditionally trying to set `min_header_version` to
the lowest possible value, and relying on a "legacy" Google interface to
determine the file descriptor's syntax version as part of that
determination.

Instead, simply bump the minimum version to 1003000 (1.3.0). This
release was almost 7 years ago. In practice protobuf-c users should not
be shipping pre-compiled .pb-c.c/.pb-c.h files, anyway.

Miscellaneous CI updates

That gives us the entire weekend to investigate build failures.

Update actions

Simplify the CI steps command so in case we use another generator
than Make for example ninja or nmake we could also support it.
Signed-off-by: Clément Péron <peron.clem@gmail.com>