NearestPointOnLine is not on the line

Recall that Section 3.3.1 of RFC 7946 defines a segment of a LineString not as a geodesic, but rather a straightforward linear interpolation between the coordinates of both points:

[...] every point on a line [...] can be calculated as

F(lon, lat) = (lon0 + (lon1 - lon0) * t, lat0 + (lat1 - lat0) * t)

with t being a real number greater than or equal to 0 and smaller
than or equal to 1. Note that this line may markedly differ from the
geodesic path along the curved surface of the reference ellipsoid.

turf.nearestPointOnLine(
  turf.lineString([[15,0],[0,90]]),
  [13.5, 52],
);

Gives a point with coordinates [ 14.999999999999996, 52.00952654924218 ]; which is not on the provided LineString, as there is no value for t that would satisfy the specified behavior. Looking at longitudes, t would be 0, but looking at latitudes t would have to be around 0.57. And 0 ≠ 0.57.

It looks to me as if #2717 was merged with disregard as to what a GeoJSON line actually is. If Turf wants to deviate from the spec, it should make that clear, and furthermore, be consistent with that assumption. Most other functions actually seem to follow the GeoJSON definition of line segments (#3053; afaik also union/difference family of functions).

Start with the turf.nearestPointOnLine entry point and reproduce the coordinates shown in the issue. Compare its result with the RFC 7946 linear-interpolation definition and the related discussion in #2717 and #3053. Done means the returned point lies on the supplied LineString under the documented interpretation, with relevant behavior covered by tests.