[nomaster] teaches toolbox about -Yrangepos

Unlike in master, in 2.10.x enabling -Yrangepos requires instantiating
Global with mixed in RangePositions trait.

Same story for toolboxes. Just setting Yrangepos is not enough - one
needs to mix in RangePositions into ToolboxGlobal. I didn’t know that
back then, so now I’m fixing the oversight.

The commit is marked as [nomaster], because -Yrangepos doesn’t need
special treatment in master.
SI-7463,SI-8003 Correct wrong position for {select,apply}Dynamic calls

The new positions are range positions that directly refer to the
beginning and the end of the method calls in the sources instead of
simply point to the beginning of the expression. This allows the
scala-ide to semantically highlight select- and applyDynamic method
calls, because it has only to traverse the tree and apply the color
ranges to the given position ranges.

This also fixes the position marker of an error messages related
to a wrong Dynamic method signature.
SI-8004 Resolve NoPosition error for applyDynamicNamed method call

Previously, there were no positions created for the tuples that are
generated while doing the transformation for an applyDynamicNamed call.
This led to an NoPosition error in scalac when one tries to show
position information in the AST. Furthermore, this simplifies semantic
highlighting in the scala-ide because no position information for color
ranges have to be created anymore.
SI-8005 Fixes NoPositon error for updateDynamic calls

Previously there occurred a NoPosition error when one asks for position
information in the AST because no positions were set to the trees
created during the transformation for updateDynamic calls. This commit
applies range positions to the trees in order to being able to highlight
them inside of the scala-ide.
Merge pull request #3196 from retronym/topic/3190-fixup

Corrects positions for Dynamic calls
Merge pull request #3180 from xeno-by/topic/toolbox-rangepos

teaches toolbox about -Yrangepos
SI-7548 askTypeAt returns the same type whether the source was fully or targeted type-checked

When asking for targeted typecheck, the located tree may have overloaded types
is the source isn't yet fully typechecked (e.g., a select tree for an
overloaded method). This is problematic as it can lead to unknown 'hovers',
broken hyperlinking that suddenly starts working, unresolved ScalaDoc comments,
and similar, in the Scala IDE.

With this commit we are hardening the contract of `askTypeAt` to return the
same type whether the file was fully type-checked or targeted type-checked.
This is done by preventing the typechecker to stop too early if the `located`
tree has an overloaded type. Furthermore, I'm assuming that if `located.tpe`
is of type `OverloadedType`, by letting the compiler carry-on the typechecking,
the `located.tpe` will eventually be resolved to a non-overloaded type. Said
otherwise, I expect the targeted typechecking will always terminate (if my
reasoning isn't sound, please say so).

The test provided with this commit demonstrates the new behavior (the position
used to execute the test is resolved to the `foo` method's call). In fact,
before this commit, executing the test returned the following:

    (x: Int, y: String)Unit <and> (x: String)Unit <and> (x: Int)Unit

Showing that the tree's type is an overloaded type. The ambiguity is fixed by
this commit, and in fact the test's output is now:

    (x: Int)Unit
SI-7548 Test to demonstrate residual exploratory typing bug

We shouldn't observe tree types under silent mode.

The enclosed test is a standalone version of `1 + BigInt(2)`,
a standard example of exploratory typing in Scala. Once we determine
that none of the `+` methods in `Int` accepts (possibly implicitly
coerced `BigInt`), we have to backtrack and look for a view from
`Int => { +(_: BigInt): ? }`.

The next commit will correct the problem.
SI-7458 Pres. compiler must not observe trees in silent mode

Otherwise we can think that `+` in `1 + BigInt(2)` refers
to a method in `Int`.

In general, this protects the IDE from observing results from
"exploratory" typing which is discarded as the compiler backtracks
to another possibility.

This protection subsumes the condition that checked for overloaded
types: presentation/t7458 now passes without this.
Merge pull request #3208 from dotta/si-7548-on-2.10

 askTypeAt returns the same type for full/ targeted typecheck (2.10.x)
SI-6913 Fixing semantics of Future fallbackTo to be according to docs

Origin: viktorklang@1bbe854