Presentation compiler hyperlinking on context bounds test

Added test to the presentation compiler regression suite to exercise
hyperlinking on context bounds.
SI-4287 Added test demonstrating hyperlinking to constructor's argument

This test was inspired by `test/files/run/t5603`, whose output (.check file)
will need to be updated in the upcoming commit that fixes SI-4287, because
the positions associated to the tree have slightly changed.

The additional test should demonstrate that the change in positions isn't
relevant, and it doesn't affect functionality. In fact, hyperlinking to a
constructor's argument work as expected before and after fixing SI-4287.
SI-4827 Test to demonstrate wrong position of constructor default arg

As demonstrated by the attached test, hyperlinking on constructor's
default arg doesn't work (the returned tree is the parameter tree,
i.e., `f`, which is of course wrong).

Printing the tree reveals the issue:

``
[[syntax trees at end of                     typer]] // Foo.scala
[0:63]package [0:0]<empty> {
  [0:37]class Baz extends [9:37][39]scala.AnyRef {
    [10:31]<paramaccessor> private[this] val f: [14]Int = _;
    [14]<stable> <accessor> <paramaccessor> def f: [14]Int = [14][14]Baz.this.f;
    [39]def <init>([14]f: [17]<type: [17]scala.Int> = [30]B.a): [9]Baz = [39]{
      [39][39][39]Baz.super.<init>();
      [9]()
    }
  };

  [6]<synthetic> object Baz extends [6][6]AnyRef {
    [6]def <init>(): [9]Baz.type = [6]{
      [6][6][6]Baz.super.<init>();
      [9]()
    };
    [14]<synthetic> def <init>$default$1: [14]Int = [30]B.a
  };
  [39:63]object B extends [48:63][63]scala.AnyRef {
    [63]def <init>(): [48]B.type = [63]{
      [63][63][63]B.super.<init>();
      [48]()
    };
    [52:61]private[this] val a: [56]Int = [60:61]2;
    [56]<stable> <accessor> def a: [56]Int = [56][56]B.this.a
  }
}
``

In short, the default argument in `<init>` (the constructor) has an
offset position, while we would expect it to have a range position.
Therefore, when locating a tree for any position between (start=) 10
and (end=) 31, the paramaccessor tree `f` is returned.

The next commit will correct the problem.
SI-4827 Corrected positions assigned to constructor's default arg

* Default arguments are always retained on the <init> method (i.e.,
  the class' constructor). Therefore, when the <init> parameters are
  created, we need to use `duplicateAndKeepPositions` to make sure that
  if a default argument is present, its opaque position is retained as
  well. This is necessary because when parameter accessors (i.e.,
  `fieldDefs`) are created, all default arguments are discared ( as you
  can see in the code, the right-hand-side of a `field` is always an
  `EmptyTree`) - see changes in TreeGen.scala

* When constructing the `fieldDefs`, it is important to adapt their
  range position to avoid overlappings with the positions of default
  arguments. It is worth noting that updating the field's end position
  to `vd.rhs.pos.start` would be incorrect, because `askTypeAt(pos)`
  could return the incorrect tree when the position is equal to
  `vd.rhs.pos.start` (because two nodes including that point position
  would exist in the tree, and `CompilerControl.locateTree(pos)` would
  return the first tree that includes the passed `pos`). This is why
  `1` is subtracted to `vd.rhs.pos.start`. Alternatively, we could have
  used `vd.tpt.pos.end` with similar results. However the logic would
  have become slightly more complex as we would need to handle the case
  where `vd.tpt` doesn't have a range position (for instance, this can
  happen if `-Yinfer-argument-types` is enabled). Therefore, subtracting
  `1` from `vd.rhs.pos.start` seemed the cleanest solution at the
  moment. - see changes in TreeGen.scala.

* If the synthetic constructor contains trees with an opaque range
  position (see point above), it must have a transparent position.
  This can only happen if the constructor's parameters' positions are
  considered, which is why we are now passing `vparamss1` to
  `wrappingPos` - see changes in TreeGen.scala.

* The derived primary constructor should have a transparent position
  as it may contain trees with an opaque range position. Hence, the
  `primaryCtor` position is considered for computing the position of the
  derived constructor - see change in Typers.scala.

Finally, below follows the printing of the tree for test t4287, which
you should compare with the one attached with the previous commit
message:

```
[[syntax trees at end of typer]] // Foo.scala
[0:63]package [0:0]<empty> {
  [0:37]class Baz extends [9:37][39]scala.AnyRef {
    [10:20]<paramaccessor> private[this] val f: [14]Int = _;
    [14]<stable> <accessor> <paramaccessor> def f: [14]Int = [14][14]Baz.this.f;
    <10:31>def <init>(<10:31>f: [17]<type: [17]scala.Int> = [23:31]B.a): [9]Baz = <10:31>{
      <10:31><10:31><10:31>Baz.super.<init>();
      <10:31>()
    }
  };
  [6]<synthetic> object Baz extends [6][6]AnyRef {
    [6]def <init>(): [9]Baz.type = [6]{
      [6][6][6]Baz.super.<init>();
      [9]()
    };
    [14]<synthetic> def <init>$default$1: [14]Int = [30]B.a
  };
  [39:63]object B extends [48:63][63]scala.AnyRef {
    [63]def <init>(): [48]B.type = [63]{
      [63][63][63]B.super.<init>();
      [48]()
    };
    [52:61]private[this] val a: [56]Int = [60:61]2;
    [56]<stable> <accessor> def a: [56]Int = [56][56]B.this.a
  }
}
```

You should notice that the default arg of `Baz` constructor now has a
range position. And that explains why the associated test now returns
the right tree when asking hyperlinking at the location of the default
argument.
Merge pull request #3269 from dotta/issue/si-4287

Issue/si 4287