Refactor TypeSpecifier::specifyTypesInCondition() for better readability

[thg2k]

This breaks the long if/elseif chain into separate ifs, as almost every case ends with return.

I believe this is a great improvement in code readability. Please let me know if you accept this so I can prepare the PR with the merged 2.0.x beforehand.

[ondrejmirtes]

I'm sorry, I don't think this is much of an improvement. There are several classes in PHPStan that need to handle all expression types in PHPStan:

• NodeScopeResolver (6k+ LoC)
• MutatingScope (almost 6k LoC)
• TypeSpecifier (almost 2.5k LoC)
• InitializerExprTypeResolver (2k+ LoC)

I'd like to refactor them so that all code related for example to Coalesce is in a single class in 3-4 different methods presumably. That would allow to break these into many smaller classes. But of course that's a much bigger project. This PR does not get any close to that.

[thg2k]

Well my follow up idea was to replace all ifs() with methods named like resolveExpr_Coalesce() and invoke them using the name of the expression class, much like the pretty printer class from php-parser, from there it would be easier to go towards your idea of a class-per-expression instead of method-per-expression, but it seems a bit hard to go there in one step. The idea of this PR was to get there in much smaller steps.. and taken by itself it's already an improvement to break the if/elseifs chain.

About the other three classes you mentioned, I had similar PRs ready, but they are based on the 1.11 as I experimented with it a while ago. I submitted only this one to check the reaction before investing the time to rebase them.