Remove array_filter mixed handling which breaks type specification

[herndlm]

This adapts ArrayFilterFunctionReturnTypeReturnTypeExtension to not handle a mixed argument anymore with a BenevolentUnionType.

This fixes truthy type specification with is_array && array_filter if the input is mixed, but I guess this is just a side-effect and there might be a better fix..
Context / use case: phpstan/phpstan-webmozart-assert#101

Without the modifications here I'd get

1) PHPStan\Analyser\TypeSpecifierTest::testCondition with data set #90 (PhpParser\Node\Expr\BinaryOp\BooleanAnd Object (...), array('array<string, mixed>', 'array<string, mixed>'), array())
if (is_array($foo) && array_filter($foo, 'is_string', ARRAY_FILTER_USE_KEY) === $foo)
Failed asserting that two arrays are identical.
--- Expected
+++ Actual
@@ @@
 Array &0 (
-    '$foo' => 'array<string, mixed>'
-    'array_filter($foo, 'is_string', ARRAY_FILTER_USE_KEY)' => 'array<string, mixed>'
+    '$foo' => 'array'
+    'array_filter($foo, 'is_string', ARRAY_FILTER_USE_KEY)' => '(array|null)'
 )

BUT I'm also aware that the changes here might be negatively affecting array_filter behaviour pre PHP 8, see https://3v4l.org/sOWbb. Is there a better / more pragmatical way to improve this? On the other hand, is PHPStan actively supporting PHP quirks with warnings and such?

The main problem / limitation that I have is apparently how TypeSpecifier handles the BooleanAnd expression.

• In https://github.com/phpstan/phpstan-src/blob/1.4.6/src/Analyser/TypeSpecifier.php#L668 it looks at the left and right expressions and then "merges" them
• The left one (is_array) is handled via IsArrayFunctionTypeSpecifyingExtension in https://github.com/phpstan/phpstan-src/blob/1.4.6/src/Analyser/TypeSpecifier.php#L608 and makes PHPStan aware that my input var is of type ArrayType, which is good
• The right one (array_filter) though seems to be not using that information and starts from scratch again (mixed) which leads to the BenevolentUnionType which messes up my result

Any other ideas how to improve that? It looks like NodeScopeResolver is handling this a bit different and not loosing the information so to say. Or I'm misunderstanding it somehow :)

[herndlm]

This is unfortunately not the right fix but merely a workaround. I'm currently working on a more generic improvement