Problem:
When trying to serialise `eZ\Publish\API\Repository\Values\Content\ContentInfo` /  `eZ\Publish\API\Repository\Values\Content\VersionInfo` and `eZ\Publish\API\Repository\Values\Content\Location` segmentation faults are raised due to changes implemented in https://issues.ibexa.co/browse/EZP-30981.

When trying to serialise these objects (and others that contain them as sub values). This is because in an attempt to lazy load the extra values added as part of that ticket the default PHP serializer cannot handle an object of that size causing PHP to either run out of memory (or segfault ) resulting in the php thread crashing. These errors are extremely hard to isolate due to nature of the error been uncatchable.

This is problematic for caching things like search results or other more expensive queries in eZ as the `symfony/cache` heavily relies on object serialisation to work.

Possible solutions:
 1. Define `_sleep` and `_wake` magic methods in some capacity on these value objects so that they can be serialised again (By excluding / reattaching the lazy load values to objects during object serialisation if that is possible)
2. Throw errors when these objects are serialised to raise observability in the system about them not been serializable.

Other ramifications:
Generally adding these extra lazy loaded values makes it harder to debug / work on features related to ez platform core APIs. Previously values containing these classes like this could be passed to "var_dump" /  "var_export" / "dump (symfony)" / "print_r" for debugging purposes. Adding these lazy loaded attributes blocks this approach to debugging things as trying to run any of these objects through these functions causes the  lazy loaded values to be accessed resulting a near infinite output from them. This is not a huge issue but does make the dev workflow slightly harder when working with the public API.