protoc-gen-c: Explicitly construct strings where needed for protobuf 30.x

protobuf 30.x changes various APIs to return string_view's rather than
string&'s. This broke protobuf-c, since we were relying on the implicit
construction of strings from string&'s in various places.

This commit explicitly constructs strings from the string_view's
returned by the protobuf 30.x API when we need to store an owned string
(e.g. in a hash map). This maintains compatibility with older versions
of protobuf such as 3.21 in Debian/Ubuntu while extending compatibility
to the latest protobuf 30.x.

Without this commit we get lots of errors like this when compiling
against protobuf 30.x:

    protoc-gen-c/c_field.cc:119:43: error: no match for 'operator=' (operand types are 'std::map<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >::mapped_type' {aka 'std::__cxx11::basic_string<char>'} and 'google::protobuf::internal::DescriptorStringView' {aka 'absl::debian7::string_view'})

Chase compatibility issues with Google protobuf 30.0-rc1

Apparently MSVC doesn't support designated initializers for some reason.

It is only needed on older protobuf versions where absl::string_view is
not being used.

Even though google::protobuf::internal::DescriptorStringView is exposed
in public protobuf headers, it's probably not a good idea to rely on an
"internal" typedef.

According to https://protobuf.dev/news/2024-10-02/#descriptor-apis:

    v30 will update return types in descriptor (such as full_name) to be
    absl::string_view.

So `absl::string_view` is probably the right type to use here.

Also replace some uses of arrays manually allocated with new/delete with
uses of `std::vector`.

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.