BUGFIX: 4915 fusion ParsePartials cache not flushed for symlinked packages

[mhsdesign]

Resolves #4915
By reverting fix #4838
Which will lead to the original problem to resurface #4415 (but silently this time, no one will notice the cache flodding :D)

Upgrade instructions

Review instructions

Checklist

• Code follows the PSR-2 coding style
• Tests have been created, run and adjusted as needed
• The PR is created against the lowest maintained branch
• Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
• Reviewer - The first section explains the change briefly for change-logs
• Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

[mhsdesign]

After discussing this extensively with @kitsunet (thanks 🙏 ) we are sure that this is the right direction for now.

The challenges were mainly that the PARSE_PARTIAL cache is written by fusion, but fusion only "knows" a file by its include path, which might contain directory traversal /../. To normalize that we use real_path when writing the file wich will not only cleanup directory traversal but also resolve symlinks. Normally both Flow0PackageInterface::getResourcesPath and the file monitor operate on the symlinks. Even composers installed.php internally uses the symlinks directly. But due to this one resolve, we have to resolve everywhere. Resolving the symlink for the deleted files is not possible, thus we skip.
Technically flow could operate on the realpaths directly in detectChangesOnPath but using realpath on such a fundamental framework level could be uncool as it requires more rights and see neos/flow-development-collection#2491. In our case realpath is fine as its only for dev mode and also specific for fusion and well tested since Neos 8.0.

[mhsdesign]

before #4838 the realpath call would always happen inside this ParserCacheIdentifierTrait method. The "revert" ist that we call realpath again, but explicitly above, so its more obvious who and what and why.

[jonnitto]

Tested on a local project