Deduplicate constant-condition vs impossible-check reports via collectors instead of asking the type specifier inline

[ondrejmirtes]

Extracted from the resolve-type-rewrite-2 branch (follows #6125, #6129, #6130, #6131).

ConstantConditionRuleHelper::shouldSkip() asked the type specifier inline (via ImpossibleCheckTypeHelper::findSpecifiedType()) for every call-shaped condition, just to decide whether the impossible-check rule would own the report. The rework replaces that inline ask with collector-based reconciliation:

• Constant-condition rules defer call-shaped conditions into FunctionCallConstantConditionCollector instead of asking the type specifier.
• The three ImpossibleCheckType*CallRules emit an "I reported here" marker into ImpossibleCheckTypeReportedCollector when they actually report.
• A new FunctionCallConstantConditionRule (CollectedDataNode, level 4) reconciles: deferred constant-condition errors at call sites the impossible-check rules claimed are dropped; the rest are emitted with the same trait "in context of" handling as ConstantConditionInTraitRule.

Net user-visible behavior is intended to be identical; the dedup key becomes "did the impossible-check rule actually report" rather than "does the helper think it's always-X", which also removes an on-demand type-specifier ask from the rule path (one step toward the single-pass analyser). Rule unit tests change shape: the CompositeRule setups now include the impossible-check rules, so previously invisible impossible-check errors in shared fixtures become explicit expectations.

Adapted from the branch commit to 2.2.x: the rules keep listening on raw FuncCall/MethodCall/StaticCall nodes and the 3-arg ImpossibleCheckTypeHelper.

Validation: full test suite green (17772 tests), self-analysis clean, code style clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_019wqGgaD7iqL44t1KgpJS7b