Add TriaxialEllipsoid class with geometric parameters

[dabiged]

Skeleton class for a Triaxial Ellipsoid. I have implemented the basic framework and a number of properties from Issue #47 . More advanced methods raise a NotImplementedError. I have taken formula from wikipedia and this paper: https://www.sciencedirect.com/science/article/abs/pii/S0019103584711183?via%3Dihub

ToDo:

• [x] Internal Doctests using a generic watermelon triaxial ellipsoid.
• [x] Test within the class that semimajor > semimedium > semiminor.
• [x] Tests to the test directory.
• [x] realization of a triaxial ellipsoid (Vesta / Eros?)
• [ ] Examples to the gallery

Submitting this Pull request early to get feedback.

• Should the class be called TriAxialEllipsoid or TriaxialEllipsoid
• Is the current watermelon example suitable?

Reminders:

• [x] Run make format and make check to make sure the code follows the style guide.
• [ ] Add tests for new features or tests that would have caught the bug that you're fixing.
• [ ] Add new public functions/methods/classes to doc/api/index.rst and the base __init__.py file for the package.
• [ ] Write detailed docstrings for all functions/classes/methods. It often helps to design better code if you write the docstrings first.
• [ ] If adding new functionality, add an example to the docstring, gallery, and/or tutorials.
• [ ] Add your full name, affiliation, and ORCID (optional) to the AUTHORS.md file (if you haven't already) in case you'd like to be listed as an author on the Zenodo archive of the next release.

[dabiged]

I would love some feedback on this before I go much further. Implementing things like a radius method, or anything more advanced seems to require elliptic integrals which I do not feel comfortable doing.

[santisoler]

I'm wondering if we can benefit from creating some inheritance, I mean make Ellipsoid a subclass of TriaxialEllipsoid. Even though from a mathematic perspective is true (any biaxial ellipsoid is a triaxial ellipsoid with one pair of axis of equal lenght), maybe it could not bring any advantage from a code design perspective.

cc @leouieda

[leouieda]

@santisoler @dabiged this is bringing up some interesting flaws in our current design. I’m usually hesitant to add a lot of inheritance. It’s rarely a good solution in my experience. Instead, see #76 for a proposal to have a single class. I think this would fix a lot of issues with methods taking unused arguments.

[MarkWieczorek]

I am ok with geocentric_radius, but at the same time, in spherical coordinates (r, theta, phi), r is "radius". Maybe geodesists aren't used to working with spherical coordinates, so having this be explicit is ok.

[leouieda]

Alright, I finished the few things left over from this PR. Removed all of the not implemented methods instead to simplify things. We can add them later when we have the need for such calculations.