build: Bump symfony/* to 6.4

[nickvergessen]

• build: Bump symfony/* to 6.4 3rdparty#1956

Summary

Prod Packages	Operation	Base	Target
psr/log	Upgraded	2.0.0	3.0.2
stecman/symfony-console-completion	Upgraded	0.11.0	v0.13.0
symfony/console	Upgraded	v5.4.35	v6.4.12
symfony/event-dispatcher	Upgraded	v5.4.26	v6.4.8
symfony/event-dispatcher-contracts	Upgraded	v3.0.2	v3.5.0
symfony/http-foundation	Upgraded	v5.4.25	v6.4.12
symfony/mailer	Upgraded	v5.4.22	v6.4.12
symfony/mime	Upgraded	v5.4.19	v6.4.12
symfony/polyfill-intl-idn	Upgraded	v1.29.0	v1.31.0
symfony/polyfill-php83	New	-	v1.31.0
symfony/process	Upgraded	v5.4.34	v6.4.12
symfony/routing	Upgraded	v5.4.25	v6.4.12
symfony/service-contracts	Upgraded	v3.0.2	v3.5.0
symfony/polyfill-php72	Removed	v1.29.0	-
symfony/polyfill-php73	Removed	v1.28.0	-

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[come-nc]

Can we document based on the arguments? I don't think so

@nickvergessen To be precise, I think we can with https://psalm.dev/docs/annotating_code/type_syntax/conditional_types/ , but it’s a bit complicated.

Maybe we should simply add in Base:

functiongetQuestionHelper(): QuestionHelper {
/** @var QuestionHelper */return$this->getHelper('question');
}

Seeing how often this is used.

[nickvergessen]

Maybe we should simply add in Base:

I'm up for that, if we add a public interface. I don't feel like typing 3rdparty with implied assumptions

[nickvergessen]

/backport e6cd105 to stable29

[nickvergessen]

/backport e6cd105 to stable28