Rename Relations.{memberRefAndInheritanceDeps => nameHashing}

The previous name of the flag was rather specific: it indicated
whether the new source dependency tracking is supported by given Relations
object. However, there will be more functionality added to Relations that
is specific to name hashing algorithm. Therefore it makes sense to name
the flag as just `nameHashing`.

I decided to rename Relations implementation classes to be more
consistent with the name of the flag and with the purpose they serve.

The flag in AnalysisCallback (and classes implementing it) has been
renamed as well.
Fix access modifiers for newly introduced members in Relations.

We introduced some new members (related to name hashing) with an intent
to not expose them as public API. However, I missed some modifiers and
some members (like `memberRef` and `inheritance`) are public.

This commit fixes access modifiers to agree with the intent.
Make incremental compiler compatible with Scala 2.11.

The scala/scala@2d4f0f1859b957b744f9b9f222dec8e8c478a4a8 removes the
`toplevelClass` method. The recent change from
aac19fd02be94f4ef6ba98187c9cbbc2b66a60f9 introduces dependency on that
method. Combination of both changes makes incremental compiler incompatible
with Scala 2.11.

This change introduces a compatibility hack that brings back source
compatibility of incremental compiler with Scala 2.8, 2.9, 2.10 and 2.11.

The compatibility hack is making clever use implicit conversions that
can provide dummy method definitions for methods removed from Scala
compiler.

Also, the code that depends on `enclosingTopLevelClass` has been refactored
so the dependency is more centralized.
Add more documentation to Compat class in compiler interface.

Add documentation which explains how a general technique using implicits
conversions is employed in Compat class. Previously, it was hidden inside
of Compat class.

Also, I changed `toplevelClass` implementation to call
`sourceCompatibilityOnly` method that is designed for the purpose
of being a compatibility stub.
Merge pull request #1019 from gkossakowski/scala-2.11-compat

Make incremental compiler compatible with Scala 2.11.
Add support for tracking names used in Scala source files.

Tracking of used names is a component needed by the name hashing
algorithm. The extraction and storage of used names is active only when
`AnalysisCallback.nameHashing` flag is enabled and it's disabled by
default.

This change constists of two parts:

  1. Modification of Relations to include a new `names` relation
     that allows us to track used names in Scala source files
  2. Implementation of logic that extracts used names from Scala
     compilation units (that correspond to Scala source files)

The first part is straightforward: add standard set of methods in
Relations (along with their implementation) and update the logic which
serializes and deserializes Relations.

The second part is implemented as tree walk that collects all symbols
associated with trees. For each symbol we extract a simple, decoded name
and add it to a set of extracted names. Check documentation of
`ExtractUsedNames` for discussion of implementation details.

The `ExtractUsedNames` comes with unit tests grouped in
`ExtractUsedNamesSpecification`. Check that class for details.

Given the fact that we fork while running tests in `compiler-interface`
subproject and tests are ran in parallel which involves allocating
multiple Scala compiler instances we had to bump the default memory limit.

This commit contains fixes for gkossakowski/sbt#3, gkossakowski/sbt#5 and
gkossakowski/sbt#6 issues.
Merge pull request #1013 from gkossakowski/used-names-extraction

Used names extraction logic
Add hashing of public names defined in a source file.

A hash for given name in a source file is computed by combining
hashes of all definitions with given name. When hashing a single
definition we take into account all information about it except nested
definitions. For example, if we have following definition

class Foo[T] {
  def bar(x: Int): Int = ???
}

hash sum for `Foo` will include the fact that we have a class with
a single type parameter but it won't include hash sum of `bar` method.

Computed hash sums are location-sensitive. Each definition is hashed along
with its location so we properly detect cases when definition's signature
stays the same but it's moved around in the same compilation unit.

The location is defined as sequence of selections. Each selection consists
of a name and name type. The name type is either term name or type name.
Scala specification (9.2) guarantees that each publicly visible definition
is uniquely identified by a sequence of such selectors.

For example, if we have:

object Foo {
  class Bar { def abc: Int }
}

then location of `abc` is Seq((TermName, Foo), (TypeName, Bar))

It's worth mentioning that we track name-hash pairs separately for
regular (non implicit) and implicit members. That's required for name
hashing algorithm because it does not apply its heuristic when implicit
members are being modified.

Another important characteristic is that we include all inherited members
when computing name hashes.

Here comes the detailed list of changes made in this commit:

  * HashAPI has new parameter `includeDefinitions` that allows
    shallow hashing of Structures (where we do not compute hashes
    recursively)
  * HashAPI exposes `finalizeHash` method that allow one to capture
    current hash at any time. This is useful if you want to hash a list of
    definitions and not just whole `SourceAPI`.
  * NameHashing implements actual extraction of public definitions,
    grouping them by simple name and computing hash sums for each group
    using HashAPI
  * `Source` class (defined in interface/other file) has been extended to
    include `_internalOnly_nameHashes` field. This field stores
    NameHashes data structure for given source file. The NameHashes
    stores two separate collections of name-hash pairs for regular and
    implicit members.
    The prefix `_internalOnly_` is used to indicate that this is not an
    official incremental compiler's or sbt's API and it's for use by
    incremental compiler internals only. We had to use such a prefix
    because the `datatype` code generator doesn't support emitting access
    modifiers
  * `AnalysisCallback` implementation has been modified to gather all
    name hashes and store them in the Source object
  * TestCaseGenerators has been modified to implement generation of
    NameHashes
  * The NameHashingSpecification contains a few unit tests that make sure
    that the basic functionality works properly
Add overloaded constructor to HashAPI for backwards compatibility.

Add a variant of constructor to `HashAPI` that is binary and source
backwards compatible with sbt 0.13.0.
Get rid of MurmurHash.finalizeHash import in HashAPI.

That import is shadowed by the local definition of `finalizeHash`
introduced to HashAPI class.
Access `Relations.names` conditionally in TextAnalysisFormat

The `Relations.name` is available only when name hashing flag is enabled.

This fixes a regression introduced in
304796bb7aa10223e06527a1c0a183f6689c82a8.
Push down `toString` implementation in Relations hierarchy.

Each of Relations implementation should have specific `toString`
implementation. For example, only `MRelationsNameHashing` implementation
should be printing used names in toString representation.
added sbt-mode to Community-Plugins
Merge remote-tracking branch 'gkossakowski/compute-name-hashes' into 0.13
Fix #1024. Use log.debug instead of println in TrapExit.
Fix parsing and evaluation of 'all' and 'show'.  See comment in evaluatingParser.
Fix closeable streams to recreate streams for a key if the delegate was closed.
Include the key name in the streams backing file path to avoid collisions.
TaskKey[T].previous: Option[T], which returns the value of the task the last time it executed.

This requires a Format[T] to be implicitly available at the call site and requires the task
to be referenced statically (not in a settingDyn call).  References to previous task values
in the form of a ScopedKey[Task[T]] + Format[T] are collected at setting load time in the
'references' setting.  These are used to know which tasks should be persisted (the ScopedKey)
and how to persist them (the Format).

When checking/delegating previous references, rules are slightly different.

A normal reference from a task t in scope s cannot refer to t in s unless
there is an earlier definition of t in s.  However, a previous reference
does not have this restriction.  This commit modifies validateReferenced
to allow this.

TODO: user documentation
TODO: stable selection of the Format when there are multiple .previous calls on the same task
TODO: make it usable in InputTasks, specifically Parsers
Test for #1031