migrate libprotobuf 4.23 & grpc 1.55 (additionally to existing pins)

[h-vetinari]

Main discussion for this happened in #4075.

The situation:

• protobuf has a new version scheme where, the middle number is the feature level, and the "major" version corresponds to the language bindings -- e.g. v21.12 == v3.21.21 (C++) == v4.21.12 (python)
• the short-lived 22-series bumped the major version for C++ and also introduced a dependence on abseil, not just internally, but in the API. This will become painful later, but not now at least
• not only does it depend on abseil, but also abseil's test targets, which didn't compile yet with shared builds on windows and thus took a while
• libgrpc 1.55 is apparently only compatible with protobuf 4.23, hence the zip-keys here

Due to the potential fall-out from the major version bump, I'm suggesting to do a dual protobuf pin (see also #4068). This is fortuitous timing, because we've just completed a long-standing grpc-refactor as well (adding shared libs on windows, removing some run-exports for private libs), which will ease digesting that.

Closes #4068
Closes #4075
Closes #4436
Closes #4454

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[kkraus14]

This looks reasonable to me given the whole situation with things.

[ngam]

@h-vetinari are you tracking issues related to this? We need to get core deps to run (e.g., bazel is half-failing, that is, the newer zipped pins are failing). Is that anticipated or should we follow up on a case-by-case basis?

-   - package libgrpc-1.55.0-h59456c1_0 requires libprotobuf >=4.23.1,<4.24.0a0, but none of the providers can be installed

[h-vetinari]

@h-vetinari are you tracking issues related to this?

I think it would be best to reopen #4075, but I don't have the rights to do that. Bazel needs conda-forge/grpc_java_plugin-feedstock#57