[Serializer] Let DISABLE_TYPE_ENFORCEMENT keep strings that cannot be converted - #65640

For formats where every value is a string (XML, CSV, and the query string or form data mapped by #[MapQueryString] and #[MapRequestPayload]), AbstractObjectNormalizer converts the string to the declared bool, int or float. When the conversion is impossible, it throws a NotNormalizableValueException before it reads DISABLE_TYPE_ENFORCEMENT, so the option has no effect on those formats. Since #65291 the same applies to the elements of a scalar collection, which is the case of #65623: the values of a list<int> property used to reach the validator, they now stop at the serializer, and the validator never runs.

This PR makes DISABLE_TYPE_ENFORCEMENT cover those conversions: a string that cannot be converted is kept as is, the same as for formats without conversion. The default behavior does not change. Without the option, the same exception is thrown, with the same message and path.

For the DTO of #65623, the property keeps its list<positive-int> type and the validator is in charge of the values:

#[MapQueryString(serializationContext: [AbstractObjectNormalizer::DISABLE_TYPE_ENFORCEMENT => true])] QueryString $queryString

With ?ids[]=foo, the resolver reports the messages of the Assert\All constraints instead of "This value should be of type int.".

The option keeps its existing trap: values are set as is, so it only helps for properties that can hold the string (mixed, array, or a docblock type on an untyped property). A property with a native int type still fails at the constructor or the setter, the same as it does for JSON today.

Checks run: ./phpunit src/Symfony/Component/Serializer (1403 tests, green) and ./phpunit src/Symfony/Component/HttpKernel (1677 tests, green; its resolver uses the csv path). The two new tests fail on 8.1 with the conversion exception. The scenario of the issue was also run end to end through RequestPayloadValueResolver: custom messages with the option, unchanged type message without it. No test was added to HttpKernel on purpose: its lowest-dependency job would run it against a released Serializer that does not have the fix.