Weird computed Centerline

Nobody has claimed this yet.

## Description

Using left string and right string as
```cpp
LineString3d{{0.,2.,0.}, {10.,10.,0.}} /* left */,
LineString3d{{0.,-2.,0.}, {10.,-10.,0.}} /* right */,
```
where the width increases linearly.

* Expected behavior:
one would expect a centerline of kind:
{0.,0.,0}, {5.,0.,0}, {10.,0.,0}

* Actual behavior:
However what I get is
```
Centerline:
{0, 0, 0}
{5, 4, 0}
{10, 0, 0}
```

This is a behavior intrinsic to the algorithm. This algorithm is based on lanelet2's and the result is the same:
```py
from lanelet2.core import Lanelet, LineString3d, Point3d, getId

p_left_0 = Point3d(getId(), 0., 2., 0)
p_left_1 = Point3d(getId(), 10, 10, 0)
p_right_0 = Point3d(getId(), 0, -2, 0)
p_right_1 = Point3d(getId(), 10, -10, 0)
ls_left = LineString3d(getId(), [p_left_0, p_left_1])
ls_right = LineString3d(getId(), [p_right_0, p_right_1])
lanelet = Lanelet(getId(), ls_left, ls_right)

centerline = lanelet.centerline
for p in centerline:
print(p)

```
```
[id: 0 x: 0 y: 0 z: 0]
[id: 0 x: 5 y: 4 z: 0]
[id: 0 x: 10 y: 0 z: 0]
```

Reproduce the result with the two LineString3d inputs in the issue and compare the computed centerline with the expected points. Then locate the centerline implementation and its existing tests; done means the widening boundaries produce the expected centerline without breaking the corresponding algorithm behavior.

Written by the indexing model from the issue text.