Adding glz::pmr::generic

[stephenberry]

This is currently a no-go without a polymorphic variant.

STL proposal:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3153r0.html

[packit-as-a-service]

One of the tests failed for da9e832. @admin check logs None, packit dashboard https://dashboard.packit.dev/jobs/copr/3205668 and external service dashboard https://copr.fedorainfracloud.org/coprs/build/10078755/

[wilkolbrzym-coder]

PMR support for generic would be a massive win for performance! It's a shame std::variant makes allocator propagation such a pain.
One small thing I noticed: in the move constructor generic(generic&& other, const allocator_type& alloc), we're asserting that allocators match. In release builds, if they don't match, we might end up with memory corruption since the internal containers won't re-bind to the new resource. Would it be safer to fallback to a deep copy if alloc != other.alloc?

[stephenberry]

@wilkolbrzym-coder, yeah we should probably throw an error if on a move allocators don't match. But, I don't think this code will be merged as it is now, because we need a polymorphic allocator aware version of a variant.