Fix nullsafe.neverNull false positive when the ?-> operand is nullable

[clarg18]

Fixes phpstan/phpstan#14311

$a?->b on the left of ??, or inside isset()/empty(), was reported as an unnecessary nullsafe access whenever the whole $a?->b expression came out nullable, without looking at whether $a itself could be null. When $a is nullable the ?-> is exactly what produces the null the surrounding construct then handles, so it is required. Following the advice and switching to -> fatals at runtime when $a is null.

Small repro:

function resolve(bool $flag): ?Node { return $flag ? new Node() : null; }

$node = resolve($flag);   // Node|null
return $node?->id ?? 0;   // reported as "unnecessary. Use -> instead."

The check in IssetCheck now only reports when the operand is never null. When the operand is itself a nullsafe fetch with a never-null operand of its own ($nonNull?->nullable?->x), it recurses so that inner redundant link is still reported, which keeps parity with NullsafePropertyFetchRule outside these contexts. I also added the treatPhpDocTypesAsCertain tip that the sibling rule emits.

bug-7109 had assertions that encoded the old behaviour (its $this->get()?->aaa ?? 6, where get(): ?HelloWorld, was expected to be reported), so I corrected those and added bug-14311 for the fix.

[ondrejmirtes]

Don't fix what's not broken :) phpstan/phpstan#14311 (comment)

[clarg18]

You're right, thanks. I hadn't clocked that ??/isset()/empty() suppress the null-read warning, so -> and ?-> are genuinely identical inside them and the rule is correct to flag it as redundant. Closing.