Don't avoid to load trait impl .class without inliner.

When the inliner is on, it is necessary to load class
files containing the implementation of traits, i.e.,
those ending in $class.class. This is needed to be
able to inline these methods. However it is useless
if the inliner is disabled.

The previous logic avoided to put these files on the
classpath when the inliner was off. However, this
complicates things, and it makes the classpath
mechanism dependent on something totally unrelated.

On this basis, this commit removes that logic, and
instead trait impl .class files are always kept on
the classpath.
Add -Yno-load-impl-class disabling loading of $class.class files.

The parent commit, a3f71badf67bbaac1a4ba16f68211ea6e31aa473,
removed some logic preventing $class.class files to be
loaded. It did so only when the inliner was off.

Should this cause any issue, this option provides a means to
restore the old behavior by *never* loading $class.class files.

So, using -inline -Yno-load-impl-class will not load
$class.class files either (where previously -inline would
load them). The two old behaviors being available by *either*
using -inline *or* -Yno-load-impl-class (not both).
SI-7859 Value classes may wrap a non-public member

We allow value class constructors to be non-public, so to be regular,
we should also allow the same for the param accessor.

This commit uses the 'makeNotPrivate' machinery to ensure that
the backend can generate the requisite unboxing calls.

This commit:

  - refactors the code that enforced the restrictions, improving
    a few error messages and positions. The remaining restrictions
    needed some rewording in light of this change.
  - allows value classes to have non-public, val parameters.
    private[this] / protected[this] are still disallowed as value
    classes don't have a concept of `this`, and because trying to
    accomdate then would complicate the implementation.

    This means that `class C(x: Int) extends AnyVal` is not allowed,
    the user still must write `private val x: Int` or `val x: Int`.
  - Outlaw `class C()()(val x: Int) extends AnyVal` to curtail any
    bugs that might lurk in such a formulation.

The tests:

  - Show that the privacy is respected in the typer phase, under
    joint and separate compilation. We don't want a repeat performance
    of SI-6601.
  - Show that code that needs compiler-generated unboxes works under
    both compilation scenarios
  - Checks that the remaining restrictions are enforced and well
    communicated.
Remove 'hasDefaultFlag'.

This is the change which broke the compiler until I made the
changes found in 693ecffbaf.
Removing unused code.

Most of this was revealed via -Xlint with a flag which assumes
closed world. I can't see how to check the assumes-closed-world
code in without it being an ordeal. I'll leave it in a branch in
case anyone wants to finish the long slog to the merge.
Merge pull request #3004 from paulp/pr/remove-unused

Remove unused code.
clearly establishes what macro bundles are

Previously it was enough to just extend scala.reflect.macros.Macro, which
created some loopholes, but now scalac enforces that bundles:
  1) Are static (not necessarily top-level, but just static)
  2) Are traits (objects shouldn't be bundles anyway, and classes bring
     complications with their ctors which require special treatment in
     generated classes, so why support them if they don't bring anything
     new to the table?)
  3) Are monomorphic (again, this brings unnecessary complications wrt
     auxiliary code generation, so I don't see merit in supporting
     polymorphic bundles, whatever that a polymorphic bundle could mean)
  4) Don't provide concrete implementation for Macro.c (if they do then
     what is the point?)
gets rid of randomness in virtual filenames for bundles

Bundles are emitted in compilation units that wrap virtual source files.
Previously we had those virtual files named randomly to ensure freshness,
but that led to infinite compilation loops in SBT (see the commit message
for more details and a link to a scala-user discussion).

Now the names are generated deterministically from full names of bundles,
which fixes the problems with SBT.
macro bundles are now usable in repl

One of the previous commits relaxed the top-level restriction for bundles,
turning it into a requirement of staticness (i.e. bundles nested in static
objects are also okay now).

This means that we can now define bundles in repl. Almost.

There's still a little problem remaining that arises from the fact that
when compiling a line of input, repl doesn't automatically import all
previously defined symbols, but rather uses an heuristic to scan the
input and guess what symbols need to be imported.

Unfortunately for bundles, this heuristic fails, because when scanning
a macro definition that looks like `def foo = macro Macros.foo`, it thinks
that it's only necessary to import a term symbol called Macros (a vanilla
way of defining macro impls), but not a type symbol called Macros (a new
way of writing macro impls in bundles).

This commit fixes the problem by making the repl look for both term and
type symbols corresponding to the identifiers used in macro definitions.
Merge pull request #2977 from sjrd/topic/remove-classpath-logic-dependent-on-inline

Don't avoid to load trait impl .class without inliner.
Merge pull request #2994 from xeno-by/topic/bundles

assorted fixes for bundles
Merge pull request #2965 from retronym/ticket/7859

SI-7859 Value classes may wrap a non-public member
harden test case to avoid parsing failure when name is keyword
refactor out common logic between various statSeq-s in parser

Partial functions are left outside of the call to statSeq to allow
re-use and overriding capabilities for quasiquotes.
refactor out range position utility constructors

This will help to re-use same logic for creating range positions even
if atPos isn't used to assign position to the tree.
SI-6841 SI-6657 add support for packages into quasiquotes and toolbox

In order to implement this a new parser entry point
`parseStatsOrPackages` that augments current parseStats with ability
to parse "package name { ... }" syntax.
minor changes due to typos
use regular macro expansion logic for unapply quasiquotes

Previously due to limited support for expansion in apply position
quasiquotes had to use a compiler hook for deconstruction.

Now it's possible to eliminate that special treatment and use
regular macro expansion logic instead.
improved handling of fresh names in quasiquotes

Parser tends to often generate random names for intermediate
synthetic trees like LabelDefs in while loops. Previously such
names were reified as is and it caused name clash problems.

Now quasiquotes reify such names into calls to fresh name generator
thus ensuring that within the same compilation unit such problems
won't occur.

In pattern matching role such names are instead replaced by free
variables with consistency checks if the same name occurs multiple
times in the tree.
make q"f(..$xs)" deconstruction symmetrical to q"f[..$xs]"

Now both return empty list for $xs when tree doesn't have
any applications/type applications.