Absolutized paths involving the scala package.

Confusing, now-it-happens now-it-doesn't mysteries lurk
in the darkness. When scala packages are declared like this:

  package scala.collection.mutable

Then paths relative to scala can easily be broken via the unlucky
presence of an empty (or nonempty) directory. Example:

  // a.scala
  package scala.foo
  class Bar { new util.Random }

  % scalac ./a.scala
  % mkdir util
  % scalac ./a.scala
  ./a.scala:4: error: type Random is not a member of package util
    new util.Random
             ^
  one error found

There are two ways to play defense against this:

 - don't use relative paths; okay sometimes, less so others
 - don't "opt out" of the scala package

This commit mostly pursues the latter, with occasional doses
of the former.

I created a scratch directory containing these empty directories:

  actors annotation ant api asm beans cmd collection compat
  concurrent control convert docutil dtd duration event factory
  forkjoin generic hashing immutable impl include internal io
  logging macros man1 matching math meta model mutable nsc parallel
  parsing partest persistent process pull ref reflect reify remote
  runtime scalap scheduler script swing sys text threadpool tools
  transform unchecked util xml

I stopped when I could compile the main src directories
even with all those empties on my classpath.
Hardening against nulls for deserialization.

When one attempts to populate data structures via
deserialization, nulls tend to show up in unlikely or
"impossible" places. Now there are a few fewer.
Merge pull request #2491 from paulp/pr/absolute-packages

Absolutized paths involving the scala package.
Merge pull request #2493 from paulp/pr/null-hardening

Hardening against nulls for deserialization.