… backslash

As of PHPCSUtils 1.0.12, the return value from `UseStatements::splitImportUseStatement()` will never include leading backslashes for use statements.

A knock-on effect of this, is that if the original group name ("prefix") contained a leading backslash, the fixer in the `DisallowMixedGroupUse` sniff would no longer correctly strip the "prefix" if a new group statement was created when the fixer was run.

I.e. the first of the new tests would previously incorrectly be fixed to:
```php
use function LeadingBackslash\OnPrefix\SubLevel\functionName;
use const LeadingBackslash\OnPrefix\{
    \LeadingBackslash\OnPrefix\Constants\CONSTANT_NAME as SOME_CONSTANT,
    \LeadingBackslash\OnPrefix\ANOTHER_NAME
};
```

This bug has now been fixed and the fixer will handle this correctly again.

Note:
* Group "prefixes" which had a leading backslash in the original code will now never have a leading backslash in the "fixed" code.
* Leading backslashes in the "partial" statements _within_ a group are not handled. This is a parse error in any PHP version and the "fixed" code will still contain a parse error, as fixing parse errors is not the responsibility of this sniff.

This behaviour has now been documented, both in the inline documentation in the sniff, as well as via a test.

Includes improving the variable name used when walking the return value of the `UseStatements::splitImportUseStatement()` method to make it abundantly clear that the "full name" in the return value from the method, is what PHP calls a "qualified name", i.e. without leading backslash.

Ref: PHPCSStandards/PHPCSUtils 590