Simplify type bounds.

I started out looking to limit the noise from empty type
bounds, i.e. the endless repetition of

  class A[T >: _root_.scala.Nothing <: _root_.scala.Any]

This led me to be reminded of all the unnecessary and
in fact damaging overreaches which are performed during parsing.
Why should a type parameter for which no bounds are
specified be immediately encoded with this giant tree:

  TypeBounds(
    Select(Select(Ident(nme.ROOTPKG), tpnme.scala_), tpnme.Nothing),
    Select(Select(Ident(nme.ROOTPKG), tpnme.scala_), tpnme.Any)
  )

...which must then be manually recognized as empty type bounds?
Truly, this is madness.

 - It deftly eliminates the possibility of recognizing
   whether the user wrote "class A[T]" or "class A[T >: Nothing]"
   or "class A[T <: Any]" or specified both bounds. The fact
   that these work out the same internally does not imply the
   information should be exterminated even before parsing completes.
 - It burdens everyone who must recognize type bounds trees,
   such as this author
 - It is far less efficient than the obvious encoding
 - It offers literally no advantage whatsoever

Encode empty type bounds as

  TypeBounds(EmptyTree, EmptyTree)

What could be simpler.
Reverting changes to AnyVals generated classes in 9a82fc0

 - Since the generator was not changed, the classes no longer represent the generated versions
SI-6898 Document AnyVal box and unbox implemention by BoxesRunTime

  - Added @boxRunTimeDoc@ and @unboxRunTimeDoc@ tokens to AnyVals
  - Doc comments refer to BoxesRunTime.java in the Scala repo
  - No comment for Unit
Merge pull request #2433 from soc/SI-7408

SI-7408 Fix test by sorting results of getDeclaredClasses
Merge pull request #2417 from paulp/pr/empty-type-bounds

Simplify type bounds.
Merge pull request #2284 from demobox/add-box-unbox-doc-comment

SI-6898 Document AnyVal box and unbox implemention by BoxesRunTime
Disabled failing bitset test.

It's a couple orders of magnitude out of whack when a test
demands a gigabyte of memory to pass. We might need to start
collecting per-test stats to avoid this kind of thing in the
future. It's a huge waste of time.
Merge pull request #2438 from paulp/pr/bitset-test

Disabled failing bitset test.
SI-7402 List extends Serializable

While we are all aware of the issues around Serialization,
I think in this case it is perfectly sound and safe to make
List serializable:

- List is not an interface, it is the base type of an ADT.
  Common behavior of its members should be reflected in the base type.
- List is sealed, there is no chance of an user providing a new
  non-serializable subtype of List.