Audit usages of cache.static

Intereting! Doing the most bold approach to see what happens. NR only for the bot.

No we only have to swap out the default backend.

Try replace serialize w/ clone (+remove tag sort), to see what breaks.

The last submitted patch, 19: 3016690-19.patch, failed testing. View results →

So it looks like:
- The originating issue found that cache.static is 3x slower than static class property caching (which is not tags aware) for some entity structures with many related objects. Fix was to use entity.memory_cache which does NOT serialize.
- Core since 8.6 uses entity.memory_cache, likely for same reasons
- The difference is, that cache.static does serialize and you get out a new built data object that is an exact copy of what you put in. The entity.memory_cache otoh gives you the same object, and if it was changed in the meantime, you get that changed version.

IF more optimizations are needed here, i can only imagine one route:
- Use https://github.com/myclabs/DeepCopy. And maybe we need / profit from a deep-clone-filter that takes __sleep / __serialize (and thus DependencySerializationTrait) into account.

I think i'm done here.

These should never have been added in the way they were IMO, but also probably predate the availability of MemoryCache as distinct from MemoryBackend.

Is there a reason not to use MemoryBackend instead of cache.static in the backend chain? I would think that would work.