SI-7915 Corrected range positions created during default args expansion

The tree created during expansion of default arguments contained trees with the
wrong type of positions. Let's discuss this with an example. Below is the tree
generated for the `foo` method in the test class included in this commit.

Before this commit:

```
[54:94]def foo(): [58]Unit = <70:90>{
  [70:79]<artifact> val qual$1: [70]Bar = [70:79][70:79][70:79]new [74:77]Bar();
  [80]<artifact> val x$1: [80]Int = [80]qual$1.bar$default$1;
  <70:90><70:83>qual$1.bar([80]x$1)
}
```

Now:

```
[54:99]def foo(): [58]Unit = <70:95>{
  <70:84><artifact> val qual$1: [70]Bar = [70:84][70:84][70:84]new [74:77]Bar();
  [85]<artifact> val x$1: [85]Int = [85]qual$1.bar$default$1;
  <70:95>[84:88]qual$1.bar([85]x$1)
}
```

Here are the list of changes:

* The synthetic `qual$1` has a transparent position, instead of a range position.
* The new Select tree (i.e., `qual$1.bar`) should always have a range position,
  because `selected` (i.e., the called method) is always visible in the source
  (in fact, this is the whole point of the fix, we need a range position or
  hyperlinking request from the Scala IDE won't work).
* The Block that contains the expanded default arguments is forced to have a
  transparent position, as it never exist in the original source.

The tricky part of the fix is the position assigned to the new Select tree,
which needs to respect the range position's invariants. In the specific case,
we ought to make sure that range positions don't overlap. Therefore, the position
assigned to the new Select tree is computed by intersecting the original Select
position (i.e., `baseFun`'s position) and the original qualifier's position
(i.e., `qual`'s position).

If you take a closer look at the range positions assigned in the tree after this
commit, you'll notice that the range position of the `qual$1`'s rhs (i.e., [70:84]),
and `qual$1.bar` (i.e., [84:88]) might seem to overlap, because the former ends where
the latter begins. However, this not the case because of the range position's
invariant 2, which states:

> Invariant 2: in a range position,  start <= point <  end

Hence, the above two positions aren't overlapping as far as the compiler is concerned.

One additional aspect (that may look like a detail) is that we make sure to never
generate a position such that its start is after its end. This is why we take the
position with the smallest end point.

Furthermore, calling `withStart` would turn any position in a range position,
which isn't desiderable in general (and, even worse, this can lead to generation
of invalid positions - bad offsets - if the computation is performed on offset
positions). Hence, the position's computation is only performed when both
`baseFun` and `qual` positions are range positions. Indeed, I expect this to be
always the case if the compiler is started with -Yrangepos.