BUGFIX: Make debugger more robust

[kitsunet]

Prevent exception inception while trying to render debug outputs.

This can happen when complex objects are encountered in stacktraces and we try to render a string representation. Example would be LazyProps in Fusion which can easily throw while evaluating. This is especially nasty as it leads to recursions if the original error being rendered occurred while trying to render this same LazyProps object, thus triggering the error handling again.

The suggested fix covers the whole argument rendering in a try/catch block, as this makes the code even more unreadable it was refactored to separate methods.

[kitsunet]

Additional discussion in this lengthy slack thread https://neos-project.slack.com/archives/C04PYL8H3/p1725052496671709

Trying to json_encode is hacky and dangerous and we should probably find another way to get the information we need, I introduced this to counter the problems of VOs in stacktraces. Modern VOs, that are not implementing __toString make stack traces within eg. the Neos 9 CR just a wall of class names without any meaningful values, but we want to see $valueObject->value in our stack trace. Just that that is convention and the value might not always be a string. In the thread I proposed an interface ala DebuggableInterface with a debugRepresentation(): string method, that needs to fully describe the object (e.g. object Neos\NeosContentRepository\Core\NodeTypeName(My.Package:NodeTypeName) - probably with shortened class name as the FQCN is readily available within the source code), to solve this issue. Implementing the default Stringable interface would also help but we decided against that and removed __toString from VOs a long while ago for valid reasons, so that is probably not going to happen.

[mhsdesign]

Okay i forgot what the general status is. Neos 9 now contains more toString objects again (though not all - see Node) Also this pr targets 8.4 because your initial change was down merged or something in the split?