JavaConversions: Restore source compatibility with 2.9

Readd an implicit conversion which was available in 2.9, the one from
`java.util.concurrent.ConcurrentMap` (`juc.ConcurrentMap`) to the (now
deprecated) type `scala.collection.mutable.ConcurrentMap`.

This implicit conversion can also be used to convert from
`juc.ConcurrentMap`
to `collection.Map` and creates an ambiguity error in
test/files/run/map_java_conversions.scala. To fix this, I have given
lower priority to the new conversion.

Moreover, update the documentation in `JavaConversions`: mark this
conversion as deprecated and mention the new conversion which replaces
it, converting to `scala.collection.concurrent.Map`.

I discussed this issue previously with Paul Phillips on scala-language:

https://groups.google.com/d/topic/scala-language/uXKRiGXb-44/discussion
Make Stream.withFilter.{map,flatMap} run in constant stack space

The included test currently fails because `map` and `flatMap` do not
run in constant stack space on a stream returned by `Stream.withFilter`,
as I reported here:
https://groups.google.com/d/msg/scala-language/WqJR38REXnk/saaSiDdmyqoJ

Fix the problem and add a simple testcase.

Note that the stack space consumed when producing an element of this stream is
proportional to the number of elements failing the test before the next
success. The stack space consumed to produce the stream itself is the
space needed to produce the first element, that is, is proportional to
the number of failures before the first success.
Remove commented out code
Cleanup testcase

No need to check the output - checking programmatically that the
produced streams are empty is enough.
exposes the notion on overriding in the API

it seems like we completely overlooked this functionality
exposes absTypeTag and absTypeOf

to be symmetric with typeTag and typeOf.

this is especially important for macro development,
since only c.AbsTypeTag context bounds can be used on macro implementations
adds weak_<:< to the API

quite a fundamental method to be left to be implemented manually
by the users of the reflection API
Fix stupid logic inversion of try-catch
reverts changes to ClassTag.Nothing

It seemed to be a good idea to have ClassTag.Nothing crash
in agreement with its incalculable nature.

However this breaks CanBuildFrom for the situations when Nothing is inferred
or provided explicitly. Hence the rollback.
Improve test for Stream.withFilter.{map,flatMap}

Test a wider range of functionality.
Also check that Stream.toSeq gives the right result.
Merge pull request #1167 from Blaisorblade/topic/stream-const-space

Make Stream.withFilter.{map,flatMap} run in constant stack space
Ensure implicit conversions to concurrent map are unambiguous

Even after the parent change, implicit conversions should still convert
ConcurrentHashMap to concurrent.Map and not to mutable.ConcurrentMap.

I'll include the comment by axel22 which prompting this change (taken
from https://github.com/scala/scala/pull/1172#issuecomment-7928285)
since it is highly informative and links to pull request comments might
not be very stable:

<<
Instead of just testing an implicit conversion to ConcurrentMap, the
test should call ConcurrentMap methods such as putIfAbsent (which
returns an Option[T]) and replace, to see if the correct Scala
concurrent map trait is being resolved.
The problem is that putIfAbsent already exists on juc.ConcurrentMap so
instead of triggering an implicit conversion, a type mismatch error is
output anyway.
And we cannot test that the correct concurrent map trait is returned
using methods like map, flatMap and friends, because concurrent map
traits extends mutable.Map anyway.

For this reason, I recommend to add this to the test:

scala> val a = new java.util.concurrent.ConcurrentHashMap[String,
String]() += (("", ""))
a: scala.collection.concurrent.Map[String,String] = Map("" -> "")

and make sure that the returned map is concurrent.Map, not
mutable.ConcurrentMap (the above += is one of the few methods in
collection that has the return type this.type).
>>
Improved fix for SI-1987, overloading in package objects.

When reformulating an errant package object overload,
don't forget to fully qualify it lest you trade one error
for another.
Merge pull request #1183 from jsuereth/fix/try-catch-inversion

Fix stupid logic inversion of try-catch
Merge pull request #1172 from Blaisorblade/topic/deprecated-conversion

JavaConversions: Restore source compatibility with 2.9
Merge pull request #1177 from scalamacros/topic/abstypeof

exposes absTypeTag and absTypeOf
Merge pull request #1182 from paulp/issue/1987

Improved fix for SI-1987, overloading in package objects.
Merge pull request #1179 from scalamacros/topic/classtag-of-nothing

reverts changes to ClassTag.Nothing
Merge pull request #1170 from scalamacros/topic/overriden

exposes overridenSymbol/overridingSymbol in API