This commit reverts part of 322f6de655

The implementation of Relation should in theory make no difference
whether an element is unmapped, or whether it is mapped to an empty
set. One of the changes in 322f6de655
introduced an optimization to the '+' operation on Relations that,
in theory, should have made no difference to the semantic.

The result of that optimization is that some mappings of the form
"elem -> Set()" are no longer inserted in the forwardMap of the
Relation.

Unfortunately, the change resulted in the breakage of #1430,
causing "set every" to behave incorrectly. There must be, somewhere
in the code, a test on the presence of a key rather than an access
via <relation>.get(), or some other access that bypasses the
supposed semantic equivalence described above. I spent several
hours trying to track down exactly the offending test, without
success.

By undoing the relevant change in 322f6de655, "set every"
works again. That however offers no guarantee that everything else
will keep working correctly; the underlying quirk in the code that
depends on this supposedly inessential detail is also still
lurking in the code, which is less than ideal.

util/relation/src/main/scala/sbt/Relation.scala

@@ -129,7 +129,7 @@ private final class MRelation[A, B](fwd: Map[A, Set[B]], rev: Map[B, Set[A]]) ex
 
   def +(pair: (A, B)) = this + (pair._1, Set(pair._2))
   def +(from: A, to: B) = this + (from, to :: Nil)
-  def +(from: A, to: Traversable[B]) = if (to.isEmpty) this else
+  def +(from: A, to: Traversable[B]) =
     new MRelation(add(fwd, from, to), (rev /: to) { (map, t) => add(map, t, from :: Nil) })
 
   def ++(rs: Traversable[(A, B)]) = ((this: Relation[A, B]) /: rs) { _ + _ }