Add downgrade-nullable-argument-mismatch config option for nullability-only argument type mismatches - #426

Summary

Closes #411: When a value with type null|string reaches a function parameter expecting string through a negated guard clause like if ($password !== null && ! is_string($password)), the type narrowing correctly computes to null|string (every non-null member is already string, so the negation leaves null reachable). The resulting diagnostic is mathematically correct - null can still reach the call. However, some projects prefer to treat this as a lower-priority warning rather than an error, since every non-null possibility already satisfies the parameter (only nullability is the gap here).
So, I added an opt-in .phpantom.toml config option [diagnostics] downgrade-nullable-argument-mismatch to downgrade the type_mismatch_argument to WARNING severity when the only unsatisfied member of an argument's union type is null. Off by default, so existing projects see no behavior change until opted in.

Changes Made

• src/config.rs - Added DiagnosticsConfig.downgrade_nullable_argument_mismatch: Option<bool> field with accessor method and two unit tests verifying parse and default-to-false behavior.
• src/diagnostics/type_errors/mod.rs - When building the type_mismatch_argument diagnostic, check if only null fails compatibility and the new option is enabled; if so, set severity to DiagnosticSeverity::WARNING. The message and diagnostic code unchanged.
• tests/integration/diagnostics_type_errors.rs - Three new integration tests: (1) issue # 411 scenario stays ERROR by default, (2) same case downgrades to WARNING when the option is enabled, (3) genuine non-null type mismatches stay as ERROR even when option is enabled.
• config-schema.json - Added downgrade-nullable-argument-mismatch boolean property to the [diagnostics] schema.
• docs/CHANGELOG.md + docs/configuration.md - Documented the new option for end users.

Checklist

• I have updated CHANGELOG.md
• I have updated the documentation (docs/)
• I have updated the config schema (config-schema.json)
• I have added/updated tests to cover my changes
• I fully understand the code that I am submitting (what it does,
  how it works, how it's organized), including any code drafted by an LLM.
• For any prose generated by an LLM, I have proof-read and copy-edited with
  an eye towards deleting anything that is irrelevant, clarifying anything
  that is confusing, and adding details that are relevant & needed.