Add computation of gravitational tensor components for point sources

[santisoler]

Add new kernel functions to compute gravity tensor components generated by point sources. Add test functions for the new feature: check that the diagonal elements satisfy the Laplace equation, compare all components against finite difference computations from the gravity acceleration. Add test class for checking the symmetry of tensor components. Refactor old test functions for point gravity: merge some functions into single ones through pytest parametrizations. Avoid using "gradient" for specifying the gravity acceleration vector: the "gravity gradient" is usually used to refer to the tensor.

Reminders:

• [ ] 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.

[santisoler]

@leouieda I finally found a very good opportunity to add a test class! The tests for tensor components symmetry has a few different cases that were hard to cover with just a few pytest parameters. So I decided it would be better to define a class for it, with different methods for each one of these cases. Let me know what do you think.

[santisoler]

I had never used a class for this before. Is the advantage only being able to hold values as attributes? Not complaining, just curious

Neither do I. I saw that xarray uses classes in their tests, mostly to group and keep tests organized and use inheritance to avoid repeating themselves. I thought that here this new class would work in that sense: group all tensor symmetry related fixtures, parameters and functions (methods now) under the same structure. I think the current scheme improves readability. Pytest parametrizations are nice to avoid repetition and buggy for loops inside test functions, but for some multi parameters cases, they fell short and create harder to read code.

To finish this PR I would:

• [ ] Add an example (or wait for the improvement of the docs and add it as a part of the User Guide)
• [ ] Check if passing g_ne is the same as passing g_en. If not, maybe add a utils function to sanitize tensor component names (we will probably use it in other forward modelling functions).