Introduce custom show for applied types

[soronpo]

When using an ecosystem with complex type classes it is easy to get lost in the large type error messages.
One method to mitigate it is using a compiler plugin like scala-clippy (which is not available for Scala 3).

This PR proposes a new approach with an addition of compiletime.hasCustomShow and compiletime.CustomShow by enabling library owners to define custom compiletime show strings for their classes. These strings will be fetched by scalac when running show if the class/type that is annotated with compiletime.hasCustomShow and has an available implicit set by compiletime.CustomShow.

Example:

import scala.compiletime.{CustomShow, hasCustomShow} @hasCustomShow trait Foo[T] type Baz = Foo["To Infinity And Beyond!"] object Foo: given CustomShow[Baz] with { type Out = "Baz" } val x: Foo["To Infinity And Beyond!"] = 1 // error

What we get is

 val x: Foo["To Infinity And Beyond!"] = 1 // error | ^ | Found: (1 : Int) | Required: Baz 

Using macros, library owners can create flexible custom show strings.

[nicolasstucki]

MiMa tests should have failed but they passed. We must investigate why this happened.

[sjrd]

How would this work with types that are not fully defined? Like if I want to print Foo[A, B, C] as A / B \ C with the recursively-shown strings for A, B and C?

[dwijnand]

Furthermore, I fear this could lead to types embedded printing differently than when not embedded, e.g Tuple2[Int, String] instead of (Int, String). There would need to be some way to hook back into the default printer. Also String doesn't allow for the output to be split and wrapped according to page width, like our Text does. But I do think this is an interesting idea!

[soronpo]

I updated the concept to have a @hasCustomShow annotation, which is a better fit for opaque types.