Overly restrictive assumption about ellipsoid radii being equal

[javagl]

There are a few places in the code that make the assumption that ellipsoids are "ellipsoids of revolution", meaning that radii.x===radii.y must hold.

Examples (not exhaustive):

• UniformState.js
• Ellipsoid.js
• ... (others might be added here...)

This assumption makes sense insofar that certain computations that are "just a bit tricky" for such ellipsoids can become really complicated when the assumption can not be made.

But given the recent changes that generalize aspects of the ellispoid handling (e.g. the Ellipsoid.default) and that allow users to essentially define "arbitrary" ellipsoids, it could make sense to review the places where the assumption about radii.x===radii.y is made, and think about whether or how this requirement could be relaxed.

(In some cases, it might even be possible to just no longer pose this requirement - but the implications and effects on the lower-level ellipsoid computations should be thought through. Maybe one could get away with some "Warning: [...] some computations may be imprecise" here or there, but that remains to be investigated...)

[kring]

A helpful member of the community pointed out to me awhile back to that our ENU -> Fixed transform also has an assumption of x==y in it. Specifically here: https://github.com/CesiumGS/cesium/blob/1.120/packages/engine/Source/Core/Transforms.js#L207

The person's claim - which I haven't independently verified but it sounds right to me - was that those two lines should be:

east.x = -up.y; // previously `-origin.y`
east.y = up.x; // previously `origin.x`

In other words, the east direction should be computed from the geodetic normal rather than the geocentric one. On an oblate spheroid like WGS84 the X and Y components of the two normals are identical, so it doesn't matter.