A problem of the @implicitNotFOund mechanism so far was that the user defined
message replaced the compiler-generated one, which might lose valuable information.

This commit adds an alternative where an @implicitNotFound message that starts
with `...` is taken as an explanation (without the ...) enabled under -explain.
The compiler-generated message is then kept as the explicit error message.

We apply the mechanism for an @implicitNotFound message for `boundary.Label`.
This now produces messages like this one:
```
-- [E172] Type Error: tests/neg-custom-args/explain/labelNotFound.scala:2:30 -------------------------------------------
2 |  scala.util.boundary.break(1) // error
  |                              ^
  |No given instance of type scala.util.boundary.Label[Int] was found for parameter label of method break in object boundary
  |---------------------------------------------------------------------------------------------------------------------
  | Explanation (enabled by `-explain`)
  |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  | A Label is generated from an enclosing `scala.util.boundary` call.
  | Maybe that boundary is missing?
   ---------------------------------------------------------------------------------------------------------------------
```

This approach mirrors the format used in `@noWarn`. There it is possible
to tag encode the category and message in the string.
```
@nowarn("cat=deprecation&msg=Implementation ...")
```

The current implementation for `explain=` only allows this tag at the
start of the string. Making the message either a old-style message or an
message in the explain.

We could extend this to support `msg=` to be able to have both a custom
message and an explain. Furthermore we could insert some flags to
explicitly state how to display the original message (for example:
not-found=hidden, not-found=in-message, not-found=in-explain).

Fixes scala#16888