feat: added stub for DataMapperInterface

[JefvdA]

Ensure TData of FormInterface is provided
Set TData on mixed since we don't know the type of the child forms Add template for in DataMapperInterface

creds to @roerbakei ;)

refs: #417

[Tomsgu]

This looks good to me. The only missing part is detecting if I pass a correct value when creating a form. Because currently I can pass anything I want.

$form = $this->createForm(SnippetType::class, $notAllowedObject); // type mismatch error

 /**
 * @template-implements DataMapperInterface<SnippetDto>
 */
class SnippetType extends AbstractType implements DataMapperInterface
{
    public function mapDataToForms(mixed $viewData, Traversable $forms): void
    {
        if ($viewData === null) {
            return;
        }

        // Does not make sense to do this check. But we still need to do it. Obvious error: 
        // Instanceof between SnippetDto and SnippetDto will always evaluate to true.
        // 🪪  instanceof.alwaysTrue
        
        //if (!$viewData instanceof SnippetDto) {
        //    throw new UnexpectedTypeException($viewData, SnippetDto::class);
        //}

        $forms = iterator_to_array($forms);
        // ...
    }
}

I am wondering if there is anything we can do about this.

[ondrejmirtes]

This is not sufficient. The stub has to be registered in extension.neon - stubFiles. Also because it's introducing generics, we need to add it to skipCheckGenericClasses like it was done here

phpstan-symfony/extension.neon

Lines 15 to 25 in dd1aaa7

	skipCheckGenericClasses:
	- Symfony\Component\Form\AbstractType
	- Symfony\Component\Form\FormBuilderInterface
	- Symfony\Component\Form\FormConfigBuilderInterface
	- Symfony\Component\Form\FormConfigInterface
	- Symfony\Component\Form\FormInterface
	- Symfony\Component\Form\FormTypeExtensionInterface
	- Symfony\Component\Form\FormTypeInterface
	- Symfony\Component\OptionsResolver\Options
	- Symfony\Component\Security\Core\Authorization\Voter\Voter
	- Symfony\Component\Security\Core\User\PasswordUpgraderInterface

[ondrejmirtes]

There are two different PRs with this stub: #418

1. Both have the same mistake of not registering the stub.
2. Both are slightly different so you should agree first how it should look like.

[stof]

This is wrong. there is no guarantee that the reference argument is replaced by a non-null value by the end of the method (and actually, the 3 core implementations of the interface have cases where the data will be null in the output)