I'd like to know your opinion on this approach before I go too far with it.

It's a follow up to this comment (specifically the part about disabling "{$bool}" etc in phpstan-strict-rules).

The idea is to eventually (separate PRs) add all pairs of types which make sense to prohibit (e.g. it makes sense to prohibit coercing null to string (not necessarily in phpstan-strict-rules), but it probably doesn't make sense to prohibit coercing int to string). Note that the configuration is only meant to prohibit type coercions (i.e. implicit), not explicit type casts. This could then replace things like:

• booleansInConditions and numericOperandsInArithmeticOperators from phpstan-strict-rules: the rules would be moved to phpstan and they'd be enabled by allowedTypeCoercions.XToY.
• forbidNullInInterpolatedString and forbidNullInBinaryOperations from shipmonk/phpstan-rules: it would be handled by existing phpstan rules and enabled by allowedTypeCoercions.nullToY.
• checkStrictPrintfPlaceholderTypes: it would be removed and instead it would be configured by allowedTypeCoercions.XToY. phpstan-strict-rules would set the flags to preserve the current default behavior.

The benefit of this approach is that it would be configured in one place and applied consistently across the rules. The downside is that it would make it harder to enable XToY in one rule, but prohibit it in another. Given the discussion in the strict printf parameter check PR, I guess it's safe to assume that there will be users with strong opinions on how it should behave for them. The DI container could pass a different TypeCoercionRuleHelper to every rule, so it has a possible solution, but there would have to be a sane way to configure it (ultimately the RuleLevelHelper has the same limitation).