Ref sbt/ivy#21

The "latest snapshot" chain resolver was assuming that there's at least
one artifact per module. I think that was the root cause of sbt#1616.

…tics

Fixes sbt#1514. Enable latest SNAPSHOT option by default

[0.13.10] Fix bincompat issue introduced in sbt#2268

withInterProjectFirst when set to true will prioritize inter-project
resolver over all other resolver and Ivy cache.
This aimed to workaround the fact that on Maven Test configuration is
considered private, and thus project dependency with `test->test`
configuration may not under some condition. The condition is when
someone resolves `x:y:1.0` and you have a subproject named and
versioned exactly that, and some other subproject tries to depend on
it. This happens when the project does not change the version number on
the Github.

Maven compatibility changes (intransitive warnings and "configuration not public")

This small set of changes, together with the compiler-bridge I wrote
(https://github.com/smarter/dotty-bridge) enables us to compile code
using Dotty in sbt, see https://github.com/smarter/dotty-example-project
for an example.

Make sbt aware of Dotty

Both continuations and macro-config set scalaVersion explicitly but since
sbt relies now on Scala 2.10 it's not needed anymore. In particular, we
can upgrade continuations to 2.10 which makes it easier to work with Java
8.

…cleanup

Upgrade Scala version in scripted tests

Call `initialize` in case symbol's `info` hadn't been completed
during normal compilation.

Also, normalize to the class symbol immediately.

Add a TODO regarding only looking at class symbols,
and thus ignoring the term symbol for objects,
as the corresponding class symbol has all the relevant info.

The only aspect of the self variable that's relevant for
incremental compilation is its explicitly declared type,
and only when it's different from the type of the class that declares it.

Technically, any self type that's a super type of the class could be ignored,
as it cannot affect external use (instantiation/subclassing) of the class.

Motivated because we want to make it more robust & configurable.
Original motivation was to diagnose a cyclic type representation,
likely due to an f-bounded existential type, as illustrated by the following:

```
class Dep {
  // The API representation for `bla`'s result type contains a cycle
  // (an existential's type variable's bound is the existential type itself)
  // This results in a stack overflow while showing the API diff.
  // Note that the actual result type in the compiler is not cyclic
  // (the f-bounded existential for Comparable is truncated)
  def bla(c: Boolean) = if (c) new Value else "bla"
}

class Value extends java.lang.Comparable[Value] { def compareTo(that: Value): Int = 1 }
```

Limit nesting (`-Dsbt.inc.apidiff.depth=N`, where N defaults to `2`),
and number of declarations shown for a class/structural type
(via `sbt.inc.apidiff.decls`, which defaults to `0` -- no limit).

Limiting nesting is crucial in keeping the size of api diffs of large programs
within a reasonable amount of RAM...

For example, compiling the Scala library, the API diff with nesting at `4`
exhausts 4G of RAM...

For refinement types, the Structure was already restricted
to declarations (and not inherited members), but all base types
were still included for a refinement's parents, which would
create unwieldy, and even erroneous (cyclic) types by expanding
all constituents of an intersection type to add all base types.

Since the logic already disregarded inherited members, it seems
logical to only include direct parents, and not all ancestor types.

```
class Dep {
  def bla(c: Boolean) = if (c) new Value else "bla"
}

class Value extends java.lang.Comparable[Value] { def compareTo(that: Value): Int = 1 }
```

Specialize two implementations for each value of the `inherit` boolean argument.
Also use a more direct way of distinguishing declared and inherited members.

backwards compat for source-dependencies/inherited-dependencies

Also a bit more complete: handle SelectFromTypeTree,
consider the self type an inheritance dependency,
and flatten any refinement types in inherited types,
to get to the symbols of their parents, instead of the
useless symbol of the refinement class.

Include inheritance dependencies in regular ones

Also, update test to reflect the self type is now seen as an inheritance dependency.

self types are local, so don't treat them like inherited types

note inheritanceSymbols dealiases, where allSymbols is constructed differently

fix NPE in source-dependencies/macro-annotation

Since pickled annotated types and symbols only mention
static annotations, whereas compilation from source
sees all annotations, we must explicitly filter annotations
in the API representation using the same criteria as the pickler,
so that we generate the same API when compiling from source
as when we're loading classfiles.

Further categorize debug output as api diff ([diff]), and
invalidation ([inv]). Since we log a ton of diagnostics,
make it a bit easier to find the relevant bits.

Adds withIncludeSynthToNameHashing.

Add toString to IvyPaths for debugging purpose

It turns out we need to have `scala-reflect.jar` on classpath to compile
the compiler bridge for the static scala instance of the launcher.

It turns out that we can leverage the`FakeResolver` that has been
implemented to use with the static launcher, and resolve a "fake
compiler bridge" using it, rather than copying it from the resources.

This also has the advantage of not requiring to change the build
definition.

This allows sbt to resolve the compiler bridge sources when using the
static launcher

Fixes sbt#2546. Ref sbt#958
scripted compiler-project/error-in-invalidated has been failing
frequently on Travis CI. It seems like incremental compiler is not
catching the change in source occasionally for `changes/A2.scala`.

Unlike other scripted macro tests, the call site of this macro is
`Provider.tree(0)`, which does not introduce internal member reference.
Instead the macro itself calls `Bar.bar(0)`. Due to sbt#2560, the expanded
tree is not traversed, and thus the reference to `Bar` is not caught
during incremental compilation.

traverse(tree: Tree) used to call super.traverse(tree) at the end.
sbt/sbt@0f61629 brought the traversing
call to inside of the pattern matching.
For the case of MacroExpansionOf(original), it amounts to not traveling
the macro-expanded code. See
sbt/src/sbt-test/source-dependencies/macro-nonarg-dep for the repro.

Fixes incremental compiler missing member ref from macro expansion sbt#2560

Off-the-grid installation of sbt

Fix for sbt#2435

Workaround jline/jline2#205