Rename TASTy reflect show to showExtractors

[nicolasstucki]

This renaming is to avoid confusion with the quote.{Expr|Type}.show method which
shows the source representation of the code.

[allanrenucci]

What about we use the same API as Scala Reflect? https://docs.scala-lang.org/overviews/reflection/symbols-trees-types.html#inspecting-trees

Inspecting Trees

Scala Reflection provides a handful of ways to visualize trees, all available through a universe. Given a tree, one can:

• use methods show or toString which print pseudo-Scala code represented by the tree.
• use method showRaw to see the raw internal tree that the typechecker operates upon.

[nicolasstucki]

We cannot override toString adding a context and implement it as an extension method. Therefore the only possible result is the raw underlying dotty tree.

The next PR will rename the current showCode (pseudo code) to show and match the Expr.show which prints the same code.

Using showRaw for what I called showExtractors would be confusing as the toString already shows the raw tree. Instead, we want the TASTy Reflect representation of the tree. Hence it is better to clearly differentiate these two. Maybe showExtractors is not the best name, but usually I use it to know which extractors to use.

[liufengyun]

LGTM

There are two minor concerns:

• The name showExtractors -- some are constructors
• The semantics of showExtractors is unclear (e.g., when there are several constructors for the same tree), which may affect the utility of the method.

[nicolasstucki]

The semantic are simple, print which extractor is needed to patter match on this tree.

Constructors have nothing to do with this method. It would be worth it to have another method showConstructors to know which constructors should be called to recreate this tree. Those two can clearly no print the same result as not all extractors/constructors are symmetrical.