SI-8703 add support for blocks with just a single expression to quasiquotes

Previously it was impossible to match a block that was constructed as

    Block(Nil, term)

Due to the fact that quasiquotes always flatten those into just term. This is
a correct behaviour for construction (for sake of consistency with parser) but
doing it in deconstruction mode make it impossible to match such blocks which
could have been constructed manually somewhere.

To fix this we just disable block flattening in deconstruction mode.
Interestingly enough this doesn't break existing code due to the fact that
quasiquote's block matcher also matches expressions as single-element blocks.

This allows to match single-element blocks with patterns like q"{ $foo }".
[backport] SI-8677 Duration: Zero - Inf should be MinusInf

Fixes #8677. Add basic tests.
This is a backport from 2.12.x of dead39dc5f21c6eac41788e93426c50ddd398c24.
SI-8708 Fix pickling of LOCAL_CHILD child of sealed classes

When a sealed class or trait has local children, they are not pickled
in as part of the children of the symbol (introduced in 12a2b3b to fix
Aladdin bug 1055). Instead the compiler adds a single child class
named LOCAL_CHILD. The parents of its ClassInfoType were wrong: the
first parent should be a class. For sealed traits, we were using the
trait itself.

Also, the LOCAL_CHILD dummy class was entered as a member of its
enclosing class, which is wrong: it represents a local (non-member)
class, and it's a synthetic dummy anyway.
Restore reporter forwarders in CompilationUnit

Deprecate them so that we can remove them in a couple of 2.11.x releases.

Plenty of plugins were probably using `unit.error` et al.
The continuations plugin was, for one (remedying this with pending PR).
Merge pull request #3868 from adriaanm/report-filter

Restore reporter forwarders in CompilationUnit
SI-8610 -Xlint is multichoice option

Make -Xlint a "multichoice" option for purposes of option parsing.

This allows turning on "lint with these warnings" instead of only
"turn off these warnings but enable other lint warnings".

```
$ scalac -Xlint:warn-adapted-args linty.scala  # lint plus a warning
$ scalac -Xlint warn-adapted-args linty.scala  # same
$ scalac -Xlint linty.scala                    # same as now
$ scalac -Xlint -- linty.scala                 # ok, not necessary
$ scalac -Xlint _ -- linty.scala               # another funky underscore
```

This would also enable Xlint options that are not standalone options,
although that is not implemented in this commit.  For example,
`-Xlint:no-missing-interpolator` could be used to disable that
warning. (There is no `-Xoption:flavor=off` syntax.) (`no-` switches
would not be enabled by `_`.)
SI-8616 Error on -deprecation:true,false

This is an error, not a crash.

Alternatively, one could define the multivalued colon case
as equivalent to specifying the option multiple times. That
would be very regular.  But sometimes it's nicer just to error out.
SI-8525 Add -Xlint:-warn-missing-interpolator

Turn off lint warnings with negating prefix, and add a lint-only
warning for the infamously nagging "Did you forget the interpolator?"

That message is made more dignified.

Without `-Xlint:false`, there is no mechanism to turn off
anonymous linters once `-Xlint` is selected.
Merge pull request #3866 from Blaisorblade/issue/8677-backport

SI-8677 Duration: Zero - Inf should be MinusInf
Merge pull request #3867 from lrytz/t8708

SI-8708 Fix pickling of LOCAL_CHILD child of sealed classes
relaxes attachment-matching rules

It came as a surprise recently, but attachments.contains/get/update/remove
require the class of the payload to match the provided tag exactly, not
taking subclassing into account. This commit fixes the oversight.
prevents some reflection APIs from destroying rangeposes

This commit continues the work started in fcb3932b32.

As we've figured out the hard way, exposing internally maintained trees
(e.g. macro application) to the user is dangerous, because they can mutate
the trees in place using one of the public APIs, potentially corrupting our
internal state.

Therefore, at some point we started duplicating everything that comes from the user
and goes back to the user. This was generally a good idea due to the reason
described above, but there was a problem that we didn't foresee - the problem
of corrupted positions.

It turns out that Tree.duplicate focuses positions in the tree being processed,
turning range positions into offset ones, and that makes it impossible for macro
users to make use of precise position information.

I also went through the calls to Tree.duplicate to see what can be done
to them. In cases when corruptions could happen, I tried to replace duplicate
with duplicateAndKeepPositions.

Some notes:

1) Tree rehashing performed in TreeGen uses duplicates here and there
(e.g. in mkTemplate or in mkFor), which means that if one deconstructs
a macro argument and then constructs it back, some of the positions in
synthetic trees might become inaccurate. That's a general problem with
synthetic trees though, so I don't think it should be addressed here.

2) TypeTree.copyAttrs does duplication of originals, which means that
even duplicateAndKeepPositions will adversely affect positions of certain
publicly accessible parts of type trees. I'm really scared to change this
though, because who knows who can use this invariant.

3) Some methods that can be reached from the public API (Tree.substituteXXX,
c.reifyXXX, c.untypecheck, ...) do duplicate internally, but that shouldn't be
a big problem for us, because nothing is irreversibly corrupted here.
It's the user's choice to call those methods (unlike with TypeTree.copyAttrs)
and, if necessary, they can fixup the positions themselves afterwards.

4) Macro engine internals (macro impl binding creation, exploratory typechecking
in typedMacroBody) use duplicate, but these aren't supposed to be seen by the user,
so this shouldn't be a problem.

5) Certain parser functions, member syntheses and typer desugarings also duplicate,
but in those cases we aren't talking about taking user trees and screwing them up,
but rather about emitting potentially imprecise positions in the first place.
Hence this commit isn't the right place to address these potential issues.
SI-8525 No anonymous lint

Turn anonymous references to `settings.lint` into named settings.

After that, trust to Adriaan to make them filterable.

There are a few remaining top-level -Y lint warnings that are
deprecated.
SI-8117 Fix bug when mixing well-positioned named and positional args

The method `missingParams` which returns undefined parameters of
a given invocation expression still assumed that named arguments can
only appear after positional ones.
SI-8590 Expand doc comments for ExecutionContext

- link to Java API docs for ForkJoinPool-based default implementation
- add example for creating an execution context from a `java.util.concurrent.ExecutorService`
- add tags for parameters and return values
- expand doc comment for `prepare`
Address pull request feedback
SI-8608 f interpolator emits constant strings

When invoking `format` is obviated by a lack of
formatting fields, then just degenerate to an
unenhanced constant string.

This means it doesn't cost anything to use
f"$$ordinary" in place of "$ordinary", which
may cause warnings under -Xlint.

Note that certain format literals, in particular
for line separator %n, are not actually literals and
can't be replaced at compile time.
Merge pull request #3874 from phaller/issue/8590

SI-8590 Expand doc comments for ExecutionContext
Merge pull request #3871 from lrytz/t8117

SI-8117 Fix bug when mixing well-positioned named and positional args
SI-8608 f-interpolator inlines StringOps

Instead of "hi".format(), emit new _root_.s.c.i.StringOps("hi").format(),
to clarify intent and avoid picking up some other implicit enhancement.

A further optimization would be to use String.format directly when
that is possible.  The ticket says it is not possible for
```
f"${BigDecimal(3.4)}%e"
```