SI-6844 restrict splicing in parameter position

Previously were a bit too permissive on how splicing in function
parameter position worked. This made confusing things like
possible:

   val x = TermName(“x”)
   q”def foo($x)”

Now you can either splice trees in that position (ValDefs) or
you have to provide type if you splice a name.
SI-8076 improve support for implicit argument list

This adds support for construction and deconstruction
of implicit argument list which was originally suggested
by @cvogt.

1. Splicing vale into implicit argument list automatically
   adds implicit flag to them:

     val x = q"val x: Int"
     q"def foo(implicit $x)"
     // <=> q"def foo(implicit x: Int)"

2. One might extract implicit argument list separately from
   other argument lists:

     val q”def foo(...$argss)(implicit ..$impl)" =
       q"def foo(implicit x: Int)
     // argss is Nil, impl contains valdef for x

   But this doesn't require you to always extract it separatly:

     val q”def foo(...$argss)" =
       q"def foo(implicit x: Int)
     // argss contains valdef for x
Tag synthetic unit with attachment

This makes it easy to differentiate unit inserted by a compiler vs unit
written by the user. Useful for quasiquotes and pretty printing.

Additionally SyntacticBlock extractor is changed to treat EmptyTree as
zero-element block.
Refactor reification of high-cardinality holes

New approach makes iterated function much more clear through aggressive
code reuse, recursion and large descriptive comment on top of it.
SI-7275 allow flattening of blocks with ..$

This commit extends current splicing rules to allow flattening of
trees into other trees.

Without such support it is impossible to correctly create vals with
patterns and use it in other location as they could expand into
multiple-statement blocks:

    scala> q"val (a, b) = (1, 2)"
    res0: reflect.runtime.universe.Tree =
    {
      <synthetic> <artifact> private[this] val x$1 = scala.Tuple2(1, 2):
    @scala.unchecked match {
        case scala.Tuple2((a @ _), (b @ _)) => scala.Tuple2(a, b)
      };
      val a = x$1._1;
      val b = x$1._2;
      ()
    }

    scala> q"..$res0; println(a + b)"
    res1: reflect.runtime.universe.Tree =
    {
      <synthetic> <artifact> private[this] val x$1 = scala.Tuple2(1, 2):
    @scala.unchecked match {
        case scala.Tuple2((a @ _), (b @ _)) => scala.Tuple2(a, b)
      };
      val a = x$1._1;
      val b = x$1._2;
      println(a.$plus(b))
    }
Address pull request feedback
Reify all blocks as syntactic blocks

Previous version of the pattern wasn't precise enough due to the
fact that synthetic units are now erased by syntactic block and
this could cause incorrect reification for cases like:

   val x = { val y = 1 }

Here syntactic block would extract one element but we still need to
reify it through syntactic block endpoint. So we can't filter based
on the number of elements extracted but rather filter on type of a
tree.
Addresses feedback from Jason

1. Adds tests for new synthetic unit stripping.
2. Marks implementation-specific parts of Holes as private.
3. Trims description of iterated method a bit.
4. Provides a bit more clear wrapper for q interpolator.
5. Refactors SyntacticBlock, adds documentation.
6. Makes q"{ ..$Nil }" return q"" to be consist with extractor.
SI-8182 Avert crash due to type args in pattern

Error out type args on binary op after emitting error.
Let the parse limp into the whirring blades.
Merge pull request #3418 from som-snytt/issue/8182-b

SI-8182 Avert crash due to type args in pattern
Merge pull request #3402 from densh/si/7275

SI-7275 allow flattening of blocks with ..$
Merge pull request #3374 from densh/si/6844-8076

SI-6844  SI-8076 improve handling of function parameters in quasiquotes
SI-8199 Account for module class suffix in -Xmax-classfile-name

The class file name of an inner class is based on the flattened
name of its owner chain.

But, if this is going to be unreasonably long, it is shortened
with the help of a MD5 hash.

However, after this shortening takes place, we sneakily add one
more character (the infamous '$') to the name when it is used
for the module class. It is thus possible to exceed the limit
by one.

The enclosed test failed on Mac with "filename too long" because
of this. I have also tested for trait implementatation classes,
but these seem to be suffixed with "$class" before the name
compactification runs, so they weren't actually a problem.

This change is binary incompatible as separately compiled
defintions and usages of named, inner classes need to agree
on this setting. Most typically, however, these long names
crop up for inner anonymous classes / functions, which are
not prone to the binary incompatiblity, assuming that their
creation hasn't be inlined to a separately compiled client.
Merge pull request #3426 from retronym/ticket/8199

SI-8199 Account for module class suffix in -Xmax-classfile-name
SI-8205 Avoid long, slow march to AIIOBE in SourceFile#lineContent

Fixing a regression from SI-8015.

The failure mode is kind of amusing: a while loop in `lineToString`
would count all the way to `Int.MaxValue`, and integer overflow
would foil a bounds check when looking for the 'LF' in 'CR'-'LF'.

Given that we're not a style checker to enforce that source files
end in a new-line, this commit accounts for EOF, and fixed the
overflow problem too.

A JUnit test exercises the bug and a few other variations of
`lineContent`.

While i was in the neighbourhood, I opted for a more efficient
means to slice out that line.
Merge pull request #3427 from retronym/ticket/8205

 Avoid long, slow march to AIIOBE in SourceFile#lineContent
SI-8205 Don't include CR in line

More penance. Extend the unit test and don't include CR
in the line text.

This is obvious, which shows how dangerous it is to refactor
without unit tests.

My very favorite bugs are off-by-one and EOL handling, followed
closely by off-by-Int.MaxValue.
Merge pull request #3429 from som-snytt/issue/8205

SI-8205 Don't include CR in line
SI-6169 Refine java wildcard bounds using corresponding tparam

When opening an existential, Java puts constraints in the context that are derived
from the bounds on the type parameters of the existentially quantified type.

Example:
```
public class Exist<T extends String> {
  // java helpfully re-interprets Exist<?> as Exists<? extends String>
  public Exist<?> foo() { throw new RuntimeException(); }
}
```

We simulate this by including those bounds in the existential type
that's created when parsing the wildcard type in a java class file.
fbounds