a note about Symbol.typeSignature

No changes to behavior, just documenting internal workings of reflection
a bit more thoroughly, one step at a time.
Revert "synchronizes pendingVolatiles"

This reverts commit 000c18a8fac60065747652368dadcd7850532f3f,
because Symbol.isStable is independent from Type.isVolatile
since fada1ef6b315326ac0329d9e78951cfc95ad0eb0.
FromJavaClassCompleter is now flag-agnostic

A minor evolution of the notion of completion + also a small performance
optimization.
removes non-determinism in reflection-sync-potpourri

Depending on the environment in which the test is run, s1 can be either
“String” or “java.lang.String”. This is one of the known non-deterministic
behaviors of our reflection, caused by prefix stripping only working for
packages defined in the root mirror. Until we fix this, I suggest we make
the test more lenient.
SI-8131 fixes residual race condition in runtime reflection

Apparently some completers can call setInfo while they’re not yet done,
which resets the LOCKED flag, and makes anything that uses LOCKED to
track completion unreliable. Unfortunately, that’s exactly the mechanism
that was used by runtime reflection to elide locking for symbols that are
known to be initialized.

This commit fixes the problematic lock elision strategy by introducing
an explicit communication channel between SynchronizedSymbol’s and their
completers. Now instead of trying hard to infer whether it’s already
initialized or not, every symbol gets a volatile field that can be queried
to provide necessary information.
SI-6411 reflection is now aware of posterasure

The `transformedType` method, which is used to bring Scala types to Java
world, was written in pre-valueclass times. Therefore, this method only
called transforms from erasure, uncurry and refChecks.

Now runtime reflection becomes aware of posterasure and as a consequence
methods, which have value classes in their signatures, can be called
without having to wrap them in catch-a-crash clause.

Another facet to this fix was the realization that value classes need
to be unwrapped, e.g. C(2) needs to be transformed to just 2, when they
are used naked in method signatures (i.e. `c` in `def foo(c: C)` needs
to be unwrapped, whereas `cs: List[C]`, `cs: C*` and even `cs: Array[C]`
do not).
updates the test for by-name value class parameters
unifies method and constructor handling in JavaMirrors

This automatically brings performance fixes and correct handling of
values class / by-name params into the constructor land.
SI-7328 FieldMirrors now support value classes
SI-8092 More verify for f-interpolator

Attempt to verify the nooks and crannies of the format string.

Allows all syntax in the javadoc, including arg indexes. If the
specifier after an arg has an index that doesn't refer to the arg,
a warning is issued and the missing `%s` is prepended (just as
for a part with a leading `%n`).

Other enhancements include detecting that a `Formattable` wasn't
supplied to `%#s`.

Error messages attempt to be pithy but descriptive.
SI-7933 REPL javax.script eval is cached result

The problem is that the repl underneath the script engine evaluates input to
val res0..resN, so it is a one shot operation. To allow repetition,
compile(script) now returns a CompiledScript object whose eval method can be
called any number of times.
turns off the gilSynchronizedIfNotInited optimization

According to Jason (https://github.com/scala/scala/pull/3391#issuecomment-32904460),
this one is still causing trouble, so we have to turn it off until
we have time to debug it.
SI-8092 Refactor f-interp

A denshish refactor makes the FormatInterpolator a nice bundle
that destructures its input and flattens out the classes to
give the code some elbow room. Everything shifts left.

The `checkType` method is refolded and renamed `pickAcceptable`.

An additional test case captures the leading edge test, that
a % should follow a hole, and which is the most basic
requirement.
SI-8215: Correcting typo and splitting a long sentence in MatchIterator doc

Follow-up to 9c0ca62
SI-6169 Refine java wildcard bounds using corresponding tparam

Also fixes part of SI-8197. Necessary complement to SI-1786 (#2518),
because we now infer tighter bounds for RHSs to conform to.

When opening an existential, Java puts constraints in the typing environment
that are derived from the bounds on the type parameters of the existentially
quantified type, so let's do the same for existentials over java-defined
classes in skolemizeExistential...

Example from test case:

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

In Scala syntax, given a java-defined `class C[T <: String]`, the
existential type `C[_]` is improved to `C[_ <: String]` before skolemization,
which models what Java does (track the bounds as type constraints in the typing environment)

(Also tried doing this once during class file parsing or
when creating the existential type, but that causes cyclic errors
because it happens too early.)
SI-6169 more accurate check for raw java type encoded as existential
SI-6169 initialize before .typeParams -- just in case
SI-8207 Allow import qualified by self reference

This regressed in SI-6815 / #2374. We check if the result of
`typedQualifier(Ident(selfReference))` is a stable identifier
pattern. But we actually see the expansion to `C.this`, which
doesn't qualify.

This commit adds a special cases to `importSig` to compensate.
This is safe enough, because the syntax prevents the following:

	scala> class C { import C.this.toString }
	<console>:1: error: '.' expected but '}' found.
	       class C { import C.this.toString }
	                                        ^
So loosening the check here doesn't admit invalid programs.
I've backed this up with a `neg` test.

The enclosed test also checks that we can use the self
reference in a singleton type, and as a qualifier in
a type selection (These weren't actually broken.)

Maybe it would be more principled to avoid expanding the self
reference in `typedIdent`. I can imagine that the current situation
is a pain for refactoring tools that try to implement a rename
refactoring, for example.

Seems a bit risky at the minute, but I've noted the idea
in a comment.
Rename EmptyTypTree into SyntacticEmptyTypeTree

1. Change the name as Eugene believes previous name was misleading

2. Remove EmptyTree case as it's not needed any longer
Represent tq"" as SyntacticEmptyTypeTree rather than TypeTree()

Such representation codifies the fact that type tree that doesn't have
embedded syntactic equivalent must have been inferred or otherwise
provided by the compiler rather than specified by the end user.

Additionally it also ensures that we can still match trees without
explicit types (e.g. vals without type) after typechecking. Otherwise
the same quote couldn't be used in situations like:

    val q"val x = 42" = typecheck(q"val x = 42")