Add missing `configs` method from Project to the build.sbt DSL.

* Create `configs` method for the sbt DSL
* Add ProjectManipulation for this method to implement.
Add toString methods to classloaders, for debugging.

* Add toString methods to all classloader classes.
Fix issue where ScalaInstance broke the thread-context-classloader for all scala classes.

The issue is that when you manually set a ScalaInstance, i.e. not one from Ivy, the
classpath which is returned for any given configuration ONLY uses Ivy.   This means that
the legitimate Scala JAR files that need to be on the classpath are missing from the list.
For some reason, the way we instantiate tests uses an unfiltered classloader against the
ScalaInstance, *BUT* the thread-context-classloader DOES use a filtered instance by
classpath.   This add the hook into the TestFramework runner creation so that
the classpath accurately reflects the jars needed.

cc @rkuhn
Removing printlns and adding the test, DOH.
Merge pull request #1584 from sbt/wip/fix-test-classloader-issues

Fix issues with specifying scalaHome/scalaInstance and running tests
Adding test for broken "set every", see #1430

To test, use:
> scripted tests/set-every
This commit reverts part of 322f6de6551665cade7d56b532348ea5dc3d54db

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 322f6de6551665cade7d56b532348ea5dc3d54db
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 322f6de6551665cade, "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.