Improve UnaryPlus and UnaryMinus support in isDynamicExpr

[JulianCBC]

This expands support in ExprAnalyzer::isDynamicExpr() for UnaryPlus and UnaryMinus to unwrap the expression for the purposes of determining if it's dynamic instead of only allowing numbers.

This also contains a tiny bit of refactoring to reduce the indentation in the isDynamicExpr() method as it was getting a bit deep.

This expands on the original (and correct) fix for rectorphp/rector#8261 to generalise the fix for just about every possible scenario.

From my investigation, adding a - or a + to the front of just about any expression is valid syntax, but determining what is and isn't going to produce a TypeError on execution was deemed to be too costly for what is ultimately a pretty "trivial" check, and policing "good" code by my standards is pretty pointless, all things considered.

This obviously allows a lot of really bad and stupid code past. E.g. all of these are valid syntax but obviously will crash with TypeErrors when executed:

define("STRING_CONSTANT", "crash");
$a = (-"crash");
$b = (-[]);
$c = (-(new DateTime()));
$d = (-STRING_CONSTANT);

And there's also a huge amount of bad, wrong and incorrect code that does work, e.g.:

define("STRING_NUMBER", "123");
$a = (-"123");
$b = (-STRING_NUMBER);

And this only covers scenarios that make sense within a couple of lines of code.

I've added some tests to the suite for InlineConstructorDefaultToPropertyRector as that was the Rector that triggered this whole story, however there should probably be a stack of direct tests on ExprAnalyzer as testing it via Rectors feels clunky.

This has been verified as a working fix by modifying InlineConstructorDefaultToPropertyRector to execute functionally equivalent code.

[JulianCBC]

The more I think about this, the more I want it to strictly follow the syntax instead of trying to be sane. One sec...

[samsonasik]

Looks good, thank you @JulianCBC