Refcatorings in TASTy reflection interface

[nicolasstucki]

This PR focuse on refactorings that have been on hold to avoid rebasing other PRs. Now is a good moment to do it as other PRs won't be too hard to rebase on this.

• Rename the reflection API from tasty.Tasty to tasty.Reflection
• Rename toTasty/toExpr (quoted to tasty trees / tasty trees to quoted) to relfect/reify in the tasty.Reflection interface
• Rename Show to Printer
• Add showCode to tasty trees
• Refactor util.{TreeAcumulator, TreeTraverser} to not need and explicit singleton type parameter ([T <: Tasty with Singleton](tasty: T)). Move them inside tasty.Reflection.

[liufengyun]

Nice refactoring 👍

If we can rename ReflectionCore to something simpler, that would be better.

[allanrenucci]

Can we discuss these renames during the next meeting?

It would be nice to reach a consensus and then try to avoid breaking the reflect API in the future.

I am personally not convinced by the following:

• toTasty/toExpr -> reflect/reify
• Tasty -> Reflection

[nicolasstucki]

toTasty is not meaningful and toExpr is overloaded with the lifters.

[nicolasstucki]

Reflection feels like a good name for the reflection API.

[nicolasstucki]

What would be simpler than ReflectionCore?

[liufengyun]

@nicolasstucki I was thinking something like Types or just Core. But as this is just an internal name, it does not matter much.

[nicolasstucki]

Types would get confused with the part that has the extractors for Types. Core is good, I will shorten it.

[nicolasstucki]

Rebased

[nicolasstucki]

Fix conflicts after rebase

[nicolasstucki]

To simplify rebasing, we should merge this one before #5416, #5388 and any new PR using TASTy reflect.

[nicolasstucki]

I should merge this before the meeting to get unblocked. WDYT @liufengyun. If needed we can rename methods later.

[nicolasstucki]

FYI people seem to be familiar with the reflect/reify names because of all the keynotes @odersky presented with this notation.