Fixes undercompilation on inheritance on same source

### background

In sbt 0.13 days, we could ignore the relationship between two classes defined
in the same `*.scala` source file, because they will be compiled anyway, and
the invalidation was done at the source file level. With class-based namehashing,
the invalidation is done at the class level, so we can no longer ignore inheritance
relationship coming from the same source, but we still have old assumptions scattered
around the xsbt-dependency implementation.

### what we see without the fix

```
[info] Compiling 1 Scala source to ...
....
[debug] [inv]   internalDependencies:
[debug] [inv]     DependencyByInheritance Relation [
[debug] [inv]     xx.B -> gg.table.A
[debug] [inv]     xx.Foo -> xx.C
[debug] [inv] ]
[debug] [inv]     DependencyByMemberRef Relation [
[debug] [inv]     xx.B -> gg.table.A
[debug] [inv]     xx.Hello -> gg.table.A
[debug] [inv]     xx.Foo -> xx.C
[debug] [inv] ]
....
Caused by: java.lang.AbstractMethodError: xx.Foo.buildNonemptyObjects(II)V
```

First, we see that `xx.C -> xx.B DependencyByInheritance` relationship is missing. Second, the error message seen is `java.lang.AbstractMethodError` happening on `xx.Foo`.

### what this changes

This change changes two if expressions that was used to filter out dependency info coming from the same source.

One might wonder why it's necessary to keep the local inheritance info, if two classes involved are compiled together anyways. The answer is transitive dependencies.
Here's likely what was happening:

1. `gg.table.A` was changed,
2. causing `xx.B` to invalidate.
3. However, because of the missing same-source inheritance, it did not invalidate `xx.C`.
4. This meant that neither `xx.Foo` was invalidated.
5. Calling transform method on a new `xx.Foo` causes runtime error.

By tracking same-source inheritance, we will now correctly invalidate `xx.C` and `xx.Foo`.
I think the assumption that's broken here is that "we don't need to track inheritance that is happening between two classes in a same source."

### Is this 2.11 only issue?

No. The simple trait-trait inheritance reproduction alone will not cause problem in Scala 2.12
because of the [compile-to-interface](http://www.scala-lang.org/news/2.12.0/#traits-compile-to-interfaces) traits.
However, not all traits will compile to interface.
This means that if we want to take advantage of the compile-to-interface traits,
we still should keep track of the same-source inheritance, but introduce some more
logic to determine whether recompilation is necessary.

Fixes sbt/zinc#417

Rewritten from sbt/zinc@05482d1

src/main/scala/xsbt/Dependency.scala

@@ -92,16 +92,21 @@ final class Dependency(val global: CallbackGlobal) extends LocateClassFile with
     }
 
     // Define processor reusing `processDependency` definition
-    val memberRef = processDependency(DependencyByMemberRef) _
-    val inheritance = processDependency(DependencyByInheritance) _
-    val localInheritance = processDependency(LocalDependencyByInheritance) _
+    val memberRef = processDependency(DependencyByMemberRef, false) _
+    val inheritance = processDependency(DependencyByInheritance, true) _
+    val localInheritance = processDependency(LocalDependencyByInheritance, true) _
+
+    @deprecated("Use processDependency that takes allowLocal.", "1.1.0")
+    def processDependency(context: DependencyContext)(dep: ClassDependency): Unit =
+      processDependency(context, true)(dep)
 
     /*
      * Handles dependency on given symbol by trying to figure out if represents a term
      * that is coming from either source code (not necessarily compiled in this compilation
      * run) or from class file and calls respective callback method.
      */
-    def processDependency(context: DependencyContext)(dep: ClassDependency): Unit = {
+    def processDependency(context: DependencyContext, allowLocal: Boolean)(
+        dep: ClassDependency): Unit = {
       val fromClassName = classNameAsString(dep.from)
 
       def binaryDependency(file: File, binaryClassName: String) =
@@ -133,11 +138,12 @@ final class Dependency(val global: CallbackGlobal) extends LocateClassFile with
           case None =>
             debuglog(Feedback.noOriginFileForExternalSymbol(dep.to))
         }
-      } else if (onSource.file != sourceFile) {
-        // Dependency is internal -- but from other file / compilation unit
+      } else if (onSource.file != sourceFile || allowLocal) {
+        // We cannot ignore dependencies coming from the same source file because
+        // the dependency info needs to propagate. See source-dependencies/trait-trait-211.
         val onClassName = classNameAsString(dep.to)
         callback.classDependency(onClassName, fromClassName, context)
-      } else () // Comes from the same file, ignore
+      }
     }
   }
 
@@ -227,7 +233,6 @@ final class Dependency(val global: CallbackGlobal) extends LocateClassFile with
       val depClass = enclOrModuleClass(dep)
       val dependency = ClassDependency(fromClass, depClass)
       if (!cache.contains(dependency) &&
-          fromClass.associatedFile != depClass.associatedFile &&
           !depClass.isRefinementClass) {
         process(dependency)
         cache.add(dependency)