Rule idea: prevent broken capturing of lazy options in OptionsResolver smart defaults

[stof]

symfony/options-resolver supports defining smart defaults that depend on the value of other options. This works by defining a default value using a Closure that has a first argument using Symfony\Component\OptionsResolver\Options as type (any other closure is just treated as being a normal default value for an option mean to contain a callable).
The object passed as this $options parameter (technically the OptionsResolver object itself, but this is an implementation detail) allows accessing options through ArrayAccess, but performs additional checks during those accesses to detect circular dependencies between options (where the default value of one option depends on another option, which tries to depend on the first one). This relies on synchronous access to those options in the callback implementing the default.

When defining a smart default involving a closure, a common mistake (which I caught in symfony/symfony#61837 (comment), but I even did this mistake myself in the past) is to capture Options object in the closure and read those dependent options later rather than synchronously, breaking the cycle detection. The proper usage is to read the options synchronously and to capture only the resolved values in the closure.

It would be great if phpstan could detect such capturing of Symfony\Component\OptionsResolver\Options in closures (either through explicit use or through arrow functions) to prevent such issue, recommending to capture the resolved values themselves.

Due to the implementation detail that OptionsResolver passes itself as the Options object by implementing that interface instead of using a "friend" object, the rule must distinguish cases where we work with the OptionsResolver type vs cases where the only type we know is Symfony\Component\OptionsResolver\Options (only the later case should trigger the rule).
As phpstan implemented the distinction between immediately-invoked callables and delayed-invoked callables for parameters, the rule might be relaxed to accept cases where the closure is invoked immediately (as that will still perform synchronous read of the resolved option value).