Re-price a stored condition operand that does not answer on the assign scope

[HawkForge]

Closes phpstan/phpstan#15479. Thanks @PupFuzz for the report and the version table.

When a condition is assigned to a variable, AssignHandler adds conditional holders for each expression the condition narrows. The holder type is the narrowing intersected with the expression's current type, and currentTypeForConditionalHolder() read that current type from the subexpression's stored result.

For $ok = $a['k'] === null || is_int($a['k']), the truthy specified types hold int|null for $a['k'], but the node they carry is the $a['k'] from the right operand. That node was walked on the left operand's falsey branch, so its stored type is mixed~null. Intersecting the two gave int, and if ($ok) narrowed $a['k'] to int. Variables were not affected because they are read from the scope state, which is why i() in the issue still worked. 2.2.17 used $scope->getType($expr) here.

The stored result is now used only when answersOnScope() holds for the assign scope. Otherwise the expression is processed on demand on that scope, the same way SwitchHandler, MatchHandler and CoalesceCompositionHelper handle a stored result that does not answer. The change is mirrored in turbo-ext/src/AssignHandler.cpp, followed by the expected turbo version bump.

tests/PHPStan/Analyser/nsrt/bug-15479.php uses the code from the issue. It fails without the fix (f() and g() give int) and passes with it, with and without the Turbo extension loaded.