Remove build.number.maven

I can't find any justification for having this information
in both build.number and build.number.maven.

They have drifted apart on the 2.10.x branch, although that
doesn't matter because build.number is correct, and loaded first,
and Ant properties are write-once.

I'm assuming that the Ant tasks in src/build/pack.xml are only
invoked through the <antcall>-s in ./build.xml.

Here's a test of that from the 2.10.x branch:

	% cat build.number
	#Tue Sep 11 19:21:09 CEST 2007
	version.major=2
	version.minor=10
	version.patch=3
	# This is the -N part of a version.  if it's 0, it's dropped from maven versions.
	version.bnum=0

	# Note: To build a release run ant with -Dbuild.release=true
	# To build an RC, run ant with -Dmaven.version.suffix=-RCN

	% cat build.number.maven
	version.major=2
	version.minor=10
	version.patch=0

	% git diff
	diff --git a/build.xml b/build.xml
	index 3a83aa4..5cb952c 100644
	--- a/build.xml
	+++ b/build.xml
	@@ -62,6 +62,9 @@ TODO:
	   <target name="distpack" depends="dist.done, docs.done">
	     <ant antfile="${src.dir}/build/pack.xml" target="pack-all.done" inheritall="yes" inh

	+  <target name="distpack.maven.info">
	+    <ant antfile="${src.dir}/build/pack.xml" target="pack-maven.info" inheritall="yes" i
	+
	   <target name="distpack-maven" depends="dist.done, docs.done">
	     <ant antfile="${src.dir}/build/pack.xml" target="pack-maven.done" inheritall="yes" i

	diff --git a/src/build/pack.xml b/src/build/pack.xml
	index 20c4034..56863ff 100644
	--- a/src/build/pack.xml
	+++ b/src/build/pack.xml
	@@ -133,6 +133,10 @@ MAIN DISTRIBUTION PACKAGING
	     <mkdir dir="${dists.dir}/maven/${version.number}"/>
	   </target>

	+  <target name="pack-maven.info">
	+    <echo message="version.patch = ${version.patch}"/>
	+  </target>
	+
	   <target name="pack-maven.libs" depends="pack-maven.start">
	     <macrodef name="mvn-copy-lib">
	       <attribute name="mvn.artifact.name"/>

	% ant distpack.maven.info
	Buildfile: /Users/jason/code/scala2/build.xml

	distpack.maven.info:

	pack-maven.info:
	     [echo] version.patch = 3

Notice how the stale `version.patch=0` in build.number.maven is
ignored.
Merge pull request #2942 from retronym/topic/build-number-maven

Remove build.number.maven
Longer timeout for repl test.

15 seconds is crazy aggressive. I have fast hardware and it's still
really easy for a test to take to fifteen seconds under load.
Merge pull request #2958 from paulp/pr/longer-timeout

Longer timeout for repl test.
SI-7853 An unsatisfying fix regression in explicit outer

The attempt to placate pos/t4970.scala in 55c6fd4 roused another
dragon.

We've got two levers here: the type of the symbol of the outer
accessor, and the type of its DefDef.

They have been historically out of sync due to the vaguaries of
finalResultType (which is far less vague since 671e6e03c7), but
the finicky operation of ExplicitOuter now has a hard time when
we try to bring them into line.

This stuff is notoriously difficult to understand because the
trees you see from `-Xprint` show a tpt derived from the method
symbol's info, and discards the actual tpt in the tree.

Rather than letting `DefDef(acc)` call `TypeTree(sym)` and use
`sym.tpe_*.finalResultType`, this commit computes the member type
of the accessor from the current class and explicitly uses that as
the return type of the outer accessor def.

We should try to push this a little deeper. I tried to put it into
`def TypeTree`, but that broke, among others,
run/concurrent-stream.scala. Maybe `def DefDef` and `def ValDef`?

But a localised fix is the right start as it addresses the regression
in a minimal fashion to get the IDE building again.
SI-7853 A less ad-hoc place to call memberType

Rather than localizing the fix to the outerAccessor, this
commit pushed the call to `memberType` into *all* usages of
`newValDef` and `newDefDef`.

The TPT of `applyOrElse` in synthetized partial functions must
be set explicitly to pass the pos/t7853-partial-function.scala.
Otherwise, the as-seen-from ends up cloning the type parameter
`B1` of `applyOrElse` as it transforms (questionably)
its bound from `List[Int @unchecked]` to `List[Int]`.

Partial Function synthesis was already a delicate area, and this
makes things more explicit which could be counted as an improvement.
Merge pull request #2955 from retronym/ticket/7853

SI-7853 Regression in explicit outer
add syntactic extractor for assignment/update trees

There are three kinds of assign-like trees:

1. Assign(lhs, rhs)                          // $lhs = $rhs
3. AssignOrNamedArg(lhs, rhs)                // $lhs = $rhs
2. Apply(Select(f, nme.update), args :+ rhs) // $f(..$args) = $rhs

New syntactic combinator unifies all of them and lets users not to think
about these implementations details.