Add a dynamic stub loader to prefer upstream types

[stof]

Once the precise types are added in Symfony, the upstream types should be used to benefit from the maintenance work of the Symfony team.

Closes#431

[stof]

The remaining stubs belong to a few categories:

• the form stubs, which will be handled in Form APIs should not be enforcing generic types that have been rejected in Symfony because of being wrong #430 as we rejected them upstream
• stubs that have not yet been submitted upstream (mostly about some array iterable value types). I plan to submit them upstream and then follow up by making the loading conditional in phpstan-symfony based on the version including them
• the Options stub that might not make sense to move upstream as is, but might be useful to implement Type refinement for options in form types #400 when inferring the option resolver shape
• stubs necessary only as dependencies of other stubs

[VincentLanglet]

In which case this will occur ?

Should we return true, just to avoid a BC break ?

[stof]

I think this could happen when using a phpstan phar without loading the project composer autoloader (which likely causes issues). Otherwise, it should not happen when using composer 2+.

I copied this condition from the stub loader of phpstan-doctrine.

[VincentLanglet]

Can't we check that the version is >= some version ?

[stof]

I could. I copied the way it was done in the existing code that I moved here (to avoid having to handle coordinated conditions between 2 loaders).
Tell me whether you want me to do the change).

For reference, InputBag shipped in version 5.1.0 of the component.

[VincentLanglet]

Didn't see it was coming from another file

[stof]

Most remaining stub types (i.e. all except form types and the Options class) have been submitted upstream in symfony/symfony#64009.
I'll prepare a follow-up PR to load those types conditionally, to be merged once the Symfony PR gets accepted.

[staabm]

what is the case for files which still are referenced in extension.neon?

are these required for every symfony version?

[stof]

See #481 (comment) where I explain that

[stof]

@VincentLanglet As the Symfony PR is merged, do you prefer that I update this PR with the conditional loading for Symfony 8.1.0 or keeping it as a follow-up PR (as this PR is already approved) ?

[VincentLanglet]

@VincentLanglet As the Symfony PR is merged, do you prefer that I update this PR with the conditional loading for Symfony 8.1.0 or keeping it as a follow-up PR (as this PR is already approved) ?

I'm fine with both. I wait for the approval from staabm anyway

[stof]

@VincentLanglet@staabm I pushed my commit handling the stubs covered in Symfony 8.1 then (I already had it ready locally).