Necessary refactorings for Property hooks

[beberlei]

This prepares the internals of ClassMetadata to go away from $reflFields as an array of ReflectionProperty and sub-classes. This is problematic in PHP 8.4, because we need to use setRawValueWithoutLazyInitialization and getRawValue instead. In the existing inheritance heirachy this is going to be messy.

This PR inlines the Persistence Reflection namespace into a new PropertyAccessors namespace and reworks the API to be wrappers of ReflectionProperty (aggregation) instead of inheritance. It also cleans up the code to avoid the references to old Doctrine proxy instances. You can access the new API via ClassMetadata::$propertyAccessors.

The PropertyAccessor interface has just two methods:

interface PropertyAccessor
{
    public function setValue(object $object, mixed $value): void;
    public function getValue(object $object): mixed;
}

For backwards compatibility ClassMetadata::$reflFields is converted from array to a new LegacyReflectionFields class that maps from property accessors to persistence-based reflection property instances. Accessing this structure emits a deprecation.

Tasks

• Add tests for all property accessors
• Static Analysis
• Think how the 2-3 left over reflFields uses in core can be handled in the future.

The actual support for property hooks should be done after this is merged in a seprate PR.

[greg0ire]

This PR inlines the Persistence Reflection namespace into a new PropertyAccessors namespace

What are the consequences for the persistence reflection namespace, and for the ODM? I suppose if there is code in persistence, it is because it is shared with the ODM?

[beberlei]

@greg0ire for now its just inline because this way its easier to test the changes fully without multi component changes. We can move the PropertyAccessors namespace into persistence if we think that will help for MongoDB.

[greg0ire]

Should all the PropertyAccessor types be marked as internal so that moving them doesn't become a breaking change?

[SenseException]

Not necessarily in scope of this PR, but I'd expect that a factory would also handle the creation of EnumPropertyAccessor and EmbeddablePropertyAccessor.

[beberlei]

There is a reason I did it this way:

The code in the factory is what was copy adapted from doctrine/persistence, and the enum and embeddable accessors are originally from the ORM code as well. Mixing them in a factory, when we potentially move part of that code out back into persistece library at some point could prove problematic.

[SenseException]

Don't we expect/assert here a deprecation trigger?

[beberlei]

I didnt pay much attention to this change, but developers downstream (like this test simulates looking at the referenced PR) might want to still access the original reflector.