fix(CtElementImpl#toString): fix toString for SniperPrinter

[nharrand]

Since recent changes, CtElement#toString() calls the default prettyprinter which can be a SniperPrinter.
AFAIU, this fails for two reasons:

• toString() clone the element before printing it, and SniperPrinter use getRoleInCompilationUnit(). But getRoleInCompilationUnit() implement a Scanner that look for the exact element in its parent children. Of course the clone has a parent but is not among the children of its parent.
• SniperPrinter require some SourceFragmentContext to be pushed on a stack to print an arbitrary element that is not a CompilationUnit. This must be initialized before.

This PR implement a POC that solves these two problems. But I am not sure if that's the direction we want to take. (Currently it makes an ugly check in toString()'s body to check what sort of printer we have, but it could be rewritten to be hidden inside SniperPrinter.)
WDYT?
@monperrus
@pvojtechovsky (if you have time) am I mistaken on the behavior of SniperPrinter?

[nharrand]

(Also, merges and fixes #3144 )

[monperrus]

Sounds like a good idea!

[pvojtechovsky]

I do not like idea to have such heavy implementation of toString which clones model and then optionally does heavy sniper printing. But you probably discussed that somewhere and probably see advantages.
The existence of non standard method toStringDebug() shows what is wrong. I think that every Java developer first expects that toString() behaves like toStringDebug() and nice and heavy printing is done by other method.
I have seen some PRs where developer called toString() ... expecting that result is fast and safe ... but it is not case of current toString calling clone and heavy pretty printer.

Anyway the solution of this PR looks good to me. 👍 I am just nor sure whether we can call SniperPrinter.super (see my comment in sources) of scan method in case we have no compilation unit (no source fragments). In such case it would be safer to create real DJPP (to call toStringDebug()), which will never by mistake call any SniperPrinter code.

[nharrand]

Ok thanks for the feedback!

So, new proposal: I don't think it makes sense to apply preprocessor with the Sniper prettyprinter in toString(). In addition it is a bit ugly to do instanceofs in toString depending on the printer.

This PR now migrates this sort of mechanism to each prettyprinter implementation. And SniperJavaPrettyPrinter does not clone anymore. It just prints without modifying the element.

WDYT?

[monperrus]

Thanks a lot!