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.
Presentation compiler hyperlinking on context bounds test

Added test to the presentation compiler regression suite to exercise
hyperlinking on context bounds.