fix(CommandHelpToAttributeRector): support concatenated string in setHelp()

[androshchuk]

Previously the rule only handled plain String_ literals. When setHelp() received a Concat expression (e.g. "line one\n" . "line two") it silently dropped the call without migrating the text to #[AsCommand(help: ...)], leaving the help text permanently lost.

Introduce resolveStringExpr() that recursively folds a Concat tree of String_ literals into a single string value. Non-literal sub-expressions (variables, function calls, …) cause the method to return null, which now also prevents the setHelp() removal — fixing the silent data-loss bug.

Problem

CommandHelpToAttributeRector only handles a plain String_ literal as the argument to setHelp(). When the argument is a concatenated string (a tree of Concat nodes), the rule exhibits two bugs:

1. Silent data loss — setHelp() is removed from the method chain (via return $node->var in the traversal callback) even though $helpString is never set, so the help text is permanently discarded.
2. No migration — because $helpString stays null, refactor() returns null and nothing is added to #[AsCommand(help: ...)].

Example that triggered the bug:

$this
    ->setHelp("First line.\n"
        . "Second line.\n"
        . "Third line.")
    ->addOption(...)

Fix

• Add resolveStringExpr(Expr): ?string — recursively folds a Concat tree of String_ literals into a single string value. Returns null for any non-literal sub-expression (variables, function calls, …).
• Replace the inline instanceof String_ check with a call to resolveStringExpr().
• Crucially, return $node->var (which removes setHelp()) now only executes when $resolvedValue !== null — so non-resolvable expressions are left untouched instead of being silently dropped.

Test

Added add_help_concatenated_string.php.inc fixture covering a setHelp() call with a multi-line concatenated string alongside another chained method call (addOption).

[TomasVotruba]

Looks good, thank you 👍