protobuf >= 30.x replaces `const std::string&` in various APIs with
its own string view type that may actually be a `absl::string_view`.
Introduce our own `compat::StringView` type that we can use instead
of `const std::string&` in order to support compiling across multiple
protobuf versions.

build.yml: Try running multiarch builds on Debian bookworm

protoc-gen-c: Log a deprecation warning when invoked as `protoc-c`

cmake: Fix build when using ninja and protobuf-c already installed

If protobuf-c is already installed on the system, the cmake build can
generate an error like the following when using the ninja backend:

    edmonds@chase{0}:/tmp/protobuf-c$ cmake -S build-cmake -B build -G Ninja
    [...]

    edmonds@chase{0}:/tmp/protobuf-c$ ninja -v -C build
    ninja: Entering directory `build'
    [1/19] cd /tmp/protobuf-c/build && /usr/bin/cmake -E env PATH="/tmp/protobuf-c/build:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/edmonds/bin:/home/edmonds/.cargo/bin:/sbin:/bin:/usr/games" /usr/bin/protoc --cpp_out /tmp/protobuf-c/build -I/usr/include -I/tmp/protobuf-c /tmp/protobuf-c/protobuf-c/protobuf-c.proto
    FAILED: CMakeFiles/protoc-generated-files protobuf-c/protobuf-c.pb.cc protobuf-c/protobuf-c.pb.h /tmp/protobuf-c/build/CMakeFiles/protoc-generated-files /tmp/protobuf-c/build/protobuf-c/protobuf-c.pb.cc /tmp/protobuf-c/build/protobuf-c/protobuf-c.pb.h
    cd /tmp/protobuf-c/build && /usr/bin/cmake -E env PATH="/tmp/protobuf-c/build:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/edmonds/bin:/home/edmonds/.cargo/bin:/sbin:/bin:/usr/games" /usr/bin/protoc --cpp_out /tmp/protobuf-c/build -I/usr/include -I/tmp/protobuf-c /tmp/protobuf-c/protobuf-c/protobuf-c.proto
    /tmp/protobuf-c/protobuf-c/protobuf-c.proto: Input is shadowed in the --proto_path by "/usr/include/protobuf-c/protobuf-c.proto".  Either use the latter file as your input or reorder the --proto_path so that the former file's location comes first.
    [2/19] /usr/bin/cc -DPACKAGE_STRING="\"protobuf-c 1.5.0\"" -DPACKAGE_VERSION=\"1.5.0\" -I/tmp/protobuf-c -I/tmp/protobuf-c/protobuf-c -I/tmp/protobuf-c/build  -MD -MT CMakeFiles/protobuf-c.dir/tmp/protobuf-c/protobuf-c/protobuf-c.c.o -MF CMakeFiles/protobuf-c.dir/tmp/protobuf-c/protobuf-c/protobuf-c.c.o.d -o CMakeFiles/protobuf-c.dir/tmp/protobuf-c/protobuf-c/protobuf-c.c.o -c /tmp/protobuf-c/protobuf-c/protobuf-c.c
    ninja: build stopped: subcommand failed.

More renaming of `protoc-c` to `protoc-gen-c`

Also rename GOOGLE_PROTOBUF_* include guard defines.

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