Replacing GMT/PyGMT backend by pure Matplotlib backend

[thurinj]

This PR implements some major changes in MTUQ plotting system. I implemented an equivalent plotting function to all existing visualization methods currently implemented in MTUQ, apart from the attribute-mapping functions, which are still the minimal matplotlib implementation - PyGMT is still preferred for those (until I figure out a clean implementation based on Cartopy eventually, but it is not priority atm).

The significant change here is that I have replaced all the default behavior/default calls from GMT/PyGMT with these new Matplotlib methods.

Here are a few examples of the visualization:

note: For the depth and hypocenter search results, I used a local database, which is not very appropriate for the 2009 event, to avoid having to wait for the Syngine download for all these origins.
You should be able to reproduce all these by running the detailed example, depth and hypocenter search from the examples folder on this branch.

All the moment tensors are plotted with a custom method based on the direct computation of the radiation coefficient of the lower half-sphere of the beachball. The values are projected on the 2D plane, and the surface is built on a regular interpolated surface. The method implements a "level of detail" approach for the density of this approximation: a dense grid for the "big beachball" and a coarser grid for the small beachball displayed on the map and depth sections (as otherwise, it could take too long to plot the beachballs based on this direct approximation method).

I'd love to have feedback on this one if you have other events to test it on, etc, but I am confident we can push it as a new visualization backend.

[rmodrak]

Hi Julien, Carl,

Thanks for this major reimplementation effort, which will bring significant benefits.

I have now looked through the source code, but yet not tried running anything myself.

Fow now, perhaps we could add an "under development" warning whenever the new matplotlib backends are called, and then go ahead and merge the pull request? Then after trying out the new backends for a few months, we could remove this warning. Does this sound okay?

thanks,
Ryan

PS I will go ahead and post the above verbatim to the GitHub later tonight (currently I'm locked out from it).

At some point later, I would like to iterate myself/coordinate with you on the following
      - use colorblind friendly colormaps

additional keyword arguments related to colorbar saturation
some possible tweaks to the underlying colormesh/contour/scatter calls
decide when it is appropriate to add gmt deprecation warnings

[thurinj]

Hi @rmodrak ,

Thanks for reviewing the code. I agree with your suggestions for future improvement. The scatter-mode for the polarities mismatch is not using a colorblind friendly colorscale, so this is appropriate. For the others, as long as we are using Viridis, we should be okay.

I've added warning message for the matplotlib backend and a dedicated one for the beachball plot (since the whole concept of it is different from most of the code that use a psmeca based approach).

I've squashed commits to remove a PDF file that was included by mistake, hence the last force-push.