Narrow explode() when the delimiter is a known substring

[paulbalandan]

Summary

PHPStan did not narrow explode($delimiter, $string, 2) to a two-element list even when a
str_contains($string, $delimiter) guard proved the delimiter is present, so destructuring
[$first, $rest] = explode(...) reported Offset 1 might not exist on non-empty-list<string>
(under reportPossiblyNonexistentGeneralArrayOffset). The report framed this as a while-only
problem, but it reproduced identically inside a plain if. This teaches the explode
return-type extension to use a known-present delimiter.

Changes

• src/Type/Php/ExplodeFunctionDynamicReturnTypeExtension.php — when the scope proves the
  delimiter occurs in the string, return array{string, string} for a limit of exactly 2,
  array{0: string, 1: string, 2?: string, ...} for a larger constant limit, and
  array{string, string, ...<string>} otherwise. Presence is probed by reconstructing
  str_contains()/str_starts_with()/str_ends_with() on the same haystack and delimiter
  (with a fully-qualified name, so the node key matches the resolved call) and checking whether
  the scope knows the result to be true.
• src/Type/Php/StrContainingTypeSpecifyingExtension.php — for str_contains(),
  str_starts_with() and str_ends_with(), also remember the call value as true in the
  truthy branch, so a bare if/while guard carries the same information ... === true
  already did.
• tests/PHPStan/Analyser/nsrt/bug-14651.php — type-inference regression covering the
  reporter's while reproducer, the if form, str_starts_with/str_ends_with guards, a
  non-empty-string variable needle, and the untouched cases (no guard, different delimiter,
  limit === 1, negative limit).

Root cause

Two gaps combined:

1. ExplodeFunctionDynamicReturnTypeExtension always returned non-empty-list<string>; it
   never consulted whether the delimiter was known to be present, so it could not prove a
   second element exists.
2. A plain if (str_contains(...)) did not remember the call's truthiness. When a
   FunctionTypeSpecifyingExtension handles a call, FuncCallHandler::specifyTypes() returns
   the extension's SpecifiedTypes directly and never unions
   handleDefaultTruthyOrFalseyContext(), so inside the branch str_contains($x, $y) stayed
   bool. (Contrast is_numeric(), which has no extension and is remembered as true, and
   str_contains($x, $y) === true, where the Identical handler pins the call to true.)
   With the call unremembered, the guard scope held only the haystack narrowing
   (non-falsy-string), which carries no "contains delimiter" information for explode to use.

The first gap is fixed in the explode extension; the second by having the string-containment
extension remember the value of the three literal-substring-proving functions. explode then
reconstructs the guard call and asks the scope for its type — the reconstructed name must be
fully-qualified because parsed calls are stored under their resolved (\str_contains(...)) key.

Test

• tests/PHPStan/Analyser/nsrt/bug-14651.php asserts the inferred explode() type across
  guarded and unguarded forms; it fails before the fix (guarded cases inferred
  non-empty-list<string>) and passes after.
• Other delimiters, a possibly-empty needle, limit === 1 and negative limits keep their
  previous types, so no new false positives are introduced.
• Probed the remembering change for fallout: make phpstan (self-analysis) is clean, and
  NodeScopeResolverTest, AnalyserIntegrationTest, and the Comparison, DeadCode,
  Functions and Variables rule suites pass — no spurious always-true reports.

Fixes phpstan/phpstan#14651

[staabm]

feel free to add more commits to the PR instead of rewriting the same commit over and over and force-push.

its easier to review as separate commits.
maintainer will squash them on merge.

[VincentLanglet]

Why are we calling getFiniteTypes and then getConstantScalarValues ? Can't we call directly getConstantScalarValues ?