Implicits to encourage more Name-dropping.

This creates implicits in cakes across the land from:

  String => TermName
  String => TypeName

And also from:

  Name => NameOps[Name]           // lower priority
  TermName => NameOps[TermName]
  TypeName => NameOps[TypeName]

What this is all about, using "drop" as a motivating example,
is that these should all work:

  "abc" drop 1                      // "bc": String
  ("abc": TermName) drop 1          // "bc": TermName
  ("abc": TypeName) drop 1          // "bc": TypeName
  (("abc": TypeName): Name) drop 1  // "bc": Name

But this should not:

  ("bc": Name)  // ambiguity error

This requires drop not being directly on Name; peer implicits
from String => TermName and String => TypeName; implicit
classes to install drop on TermName and TypeName; and a lower
priority implicit class to allow ops on Names.

Review by @xeno.by .
fix Right,Left and Either scaladoc links
Merge pull request #892 from xuwei-k/either-scaladoc

fix Right,Left and Either scaladoc links
Squashed critical enhancements to SIP-14: daemonizing global EC, giving EC to DelayedLazyVal, removing currentExecutionContext, removing impl.Future.isFutureThrowable, implementing asExecutionContext, giving a decent fallback if ForkJoinPool cannot be created
Fixing oversight in propagating the runnable into the newly created thread.
Changing to scala.concurrent.context. as namespace for the system properties for the global execution context
Merge pull request #900 from viktorklang/2.10.x

critical enhancements to SIP-14
Merge branch '2.10.x' into topic/name-implicits
Avoid conflict with String's apply.

This brought to light that Name extends (Int => Char), and
that small convenience was not paying for itself.  I updated
the places taking advantage of it to use Name#charAt.
Merge pull request #902 from paulp/topic/name-implicits

Implicits to encourage more Name-dropping.
Partest: add `instrumented` test category.

---
(taken from README)

Tests in `instrumented/` directory are executed the same way as in `run/` but
they have additional byte-code instrumentation performed for profiling. You
should put your tests in `instrumented/` directory if you are interested in
method call counts. Examples include tests for specialization (you want to
count boxing and unboxing method calls) or high-level tests for optimizer
where you are interested if methods are successfuly inlined (so they should
not be called at runtime) or closures are eliminated (so no constructors
of closures are called).

Check `scala.tools.partest.instrumented.Instrumentation` to learn how to
use the instrumentation infrastructure.

The instrumentation itself is achieved by attaching a Java agent to the
forked VM process that injects calls to profiler. Check
`scala.tools.partest.javaagent.ProfilingAgent` for details.

---

A few notes on low-level details of this change:

  * Partest now depends on asm library for byte-code instrumentation
    (`build.xml`)
  * Build additional jar called `scala-partest-javaagent.jar` that is
    used with `-javaagent:` option. (`build.xml`)
  * Set `-javaagent:` option for all tests in `instrumented/` directory.
    (`RunnerManger.scala`)
  * Introduce a new category of tests called `instrumented`.
  * Add one instrumented test to demonstrate usage and test new
    infrastructure itself. (`InstrumentationTest.scala`)

Review by @phaller.