Overhaul of JavaConver{sions,ters}.

Initially motivated by SI-5580, then just motivated.  I broke up
the opaquely named JavaConversions and JavaConverters into the following
traits encapsulating some permutation of

  { to java, to scala, bidirectional }
  { wrappers, decorators }

I named everything consistently in terms of either Wrappers
or Decorators.  Decorators install those asJava/asScala methods
onto collections of the right kind; Wrappers hide the process.

JavaConversions then reduces to an object which (ill-advisedly)
extends both WrapAsJava and WrapAsScala.  And JavaConverters is
an object extending DecorateAsScala and DecorateAsJava.  However
other more clearly named vals exist in the newly created
scala.collection.convert package object.

  val decorateAsJava  = new DecorateAsJava { }
  val decorateAsScala = new DecorateAsScala { }
  val decorateAll     = new DecorateAsJava with DecorateAsScala { }
  val wrapAsJava      = new WrapAsJava { }
  val wrapAsScala     = new WrapAsScala { }
  val wrapAll         = new WrapAsJava with WrapAsScala { }

So for instance to import asScala decorators, and only those:

  scala> import scala.collection.convert.decorateAsScala._
  import scala.collection.convert.decorateAsScala._

  scala> new java.util.ArrayList[String].asScala groupBy (x => x)
  res0: scala.collection.immutable.Map[String,scala.collection.mutable.Buffer[String]] = Map()

I propose we put those vals or a subset of them in the scala
package object rather than way down in scala.collection.convert.
Merge branch 'issue/SI-5580' of /scala/trunk into develop
An illustrative delayedInit test.
disable version numbers on windows, they're broken.
Fixes SI-5593

After hours of debugging and understanding all the root causes why
scaladoc is rummaging through the current directory for classes, I
decided to treat the symptoms rather than the cause. I'll document
the decision here in case anyone is interested:
 - in order to find documentable entities, scaladoc exhaustively
looks at all the symbols starting from the root package and going
all the way to the leaves, visiting all classes in the classpath
 - if the classpath is empty, scaladoc and scalac add "." as the
default classpath. This leads to scaladoc going on a class hunting
spree in the current directory. If it happens that the current
directory contains package objects and they're not in the expected
path (like scala.tools.nsc in build/quick/classes/.../nsc) errors
start to pop up
 - scalac is also affected by this, but to a more limited scope,
since it will lazily expand packages whenever necessary. To show
this, run the repl in the root directory of the scala source code,
after compiling scala:

scala> import build.quick.classes.compiler.scala.tools.nsc._
error: error while loading package, class file './build/quick/classes/
compiler/scala/tools/nsc/package.class' contains wrong package package

The cleanest solution I can see now is to look at the tree resulting
from compilation and use it for guidance -- I will look into this.
Merge pull request #311 from lrytz/windowsScripts

disable version numbers on windows, they're broken.
minimalist refactoring to allow annotating trees

not tested for performance, but shouldn't add any memory overhead

see https://github.com/adriaanm/scala/commit/44362c557f for an example usage
Increased the timeout from 5s to 60s to make the presentation compiler shutdown test more resilient on slow machines.
Fixed SI-5599

Eliminated the spurious warnings and made the code easier to follow.
Test case closes SI-4987.
Scaladoc: improved usecases, display full signature. Closes #5291

Makes the full signature of a use case member available, but
still hidden under a drop-down menu.
Merge remote-tracking branches 'axel22/feature/pc-execution-contexts', 'VladUreche/issue/5593', 'dragos/master', 'VladUreche/issue/5599', 'adriaanm/ticket/treeannot' and 'heathermiller/issue/5291' into develop
Revert "Made changeOwner more robust; now also deals with return expressions."

This reverts commit 19a48510c2e18430a35319c04dfe3bad7119f23f.
Test case for cause of previous commit's reversion.
Undo the revert.

reverts 3db29dde051614d976bca92a1cdeb109c9c0ab01 and 5af2bf54d21ac63236cd6e68586b2c38fa0f28c3
restores 19a48510c2e18430a35319c04dfe3bad7119f23f
Merge pull request #318 from lrytz/revRev

Undo the revert.
[vpm] typeMatchAnonFun improvements

need to set up symbols with approximated info for the method and its owner
before typing the method's body; when the body has been typed,
we know what its result type will be, so update info of class and method to reflect that

better detection of synthesized matches: annotate selector rather than relying on symbol info

encapsulate CASE | SYNTHETIC flags (setting and querying)
don't throw error in setError when -Ydebug
[vpm] avoid verifyerror: leave jump to tail-pos label

the following commit deals with the fall-out in basicblocks
(double closing of blocks in ignore mode)
do nothing when closing closed block in ignoremode

this came to light with the virtual pattern matcher, which
emits jumps like `matchEnd3(_test(Test.this, false))`, where _test is a tailcall
the nested jumping caused double-closing (the second time in ignore mode)
thus. when closing a closed block in ignore mode, simply do nothing

from genLoad for label-jumps:

note: when one of the args to genLoadLabelArguments is a jump to a label,
it will call back into genLoad and arrive at this case, which will then set ctx1.bb.ignore to true,
this is okay, since we're jumping unconditionally, so the loads and jumps emitted by the outer
call to genLoad (by calling genLoadLabelArguments and emitOnly) can safely be ignored,
however, as emitOnly will close the block, which reverses its instructions (when it's still open),
we better not reverse when the block has already been closed but is in ignore mode
(if it's not in ignore mode, double-closing is an error)

@dragos figured it out, all I did was write the comment and the `if`

test case to repro basic blocks crasher

the tailcall in the forward jump `matchEnd3(_test(Test.this, false))`
in the following program crashes the back-end (error below)

 @scala.annotation.tailrec final def test(meh: Boolean): Boolean = {
      <synthetic> val _$this: Test.type = Test.this;
      _test(_$this,meh){
        case <synthetic> val x1: Some[String] = new Some[String]("a");
        case3(){
          matchEnd2({
            case <synthetic> val x1: Some[String] = x1;
            case4(){
              if (x1.ne(null))
                matchEnd3(if (meh)
                  _test(Test.this, false)
                else
                  false)
              else
                case5()
            };
            case5(){
              matchEnd3(_test(Test.this, false))
            };
            matchEnd3(x){
              x
            }
          })
        };
        matchEnd2(x){
          x
        }
      }
    };

The last instruction (of basic block 11) is not a control flow instruction: CONSTANT(false)

  // methods
  def test(meh: Boolean (BOOL)): Boolean {
  locals: value meh, value _$this, value x1, value x, value x, value x1
  startBlock: 1
  blocks: [1,2,3,4,5,6,7,8,9,10,11,12,13]

  1:
    4	JUMP 2

  2:
    5	NEW REF(class Some)
    5	DUP(REF(class Some))
    5	CONSTANT("a")
    5	CALL_METHOD scala.Some.<init> (static-instance)
    5	STORE_LOCAL(value x1)
    5	SCOPE_ENTER value x1
    5	JUMP 3

  3:
    5	LOAD_LOCAL(value x1)
    7	STORE_LOCAL(value x1)
    7	SCOPE_ENTER value x1
    7	JUMP 4

  4:
    7	LOAD_LOCAL(value x1)
    7	CZJUMP (REF(class Object))NE ? 5 : 6

  5:
    8	LOAD_LOCAL(value meh)
    8	CZJUMP (BOOL)NE ? 8 : 9

  6:
    ?	JUMP 11

  7:
    7	DROP BOOL
    7	JUMP 11

  8:
    8	CONSTANT(false)
    8	STORE_LOCAL(value meh)
    8	JUMP 2

  9:
    8	CONSTANT(false)
    8	JUMP 10

  10:
    8	STORE_LOCAL(value x)
    8	JUMP 12

  11:
    9	JUMP 2
    9	STORE_LOCAL(value meh)
    9	CONSTANT(false)

  12:
    7	LOAD_LOCAL(value x)
    7	SCOPE_EXIT value x1
    7	STORE_LOCAL(value x)
    7	JUMP 13

  13:
    5	LOAD_LOCAL(value x)
    5	SCOPE_EXIT value x1
    5	RETURN(BOOL)