Allow ticks for geoaxes

[cvanelteren]

This PR addresses #125. It introduces a test that tests specifically three use cases.
It modifies the code to allow for showing ticks in geoaxis. Currently, the tickers are completely controlled through the backend with small modifications to ensure high quality plots. This PR makes it to add ticks. It does this by manually adding a ticker when new keywords lontick or lattick is given which can take a bool or numeric as an input. When set to None the option is effectively ignored.

The defaults should generate a sensible plot with lat and long lines, but without ticks. Then it specifically tests whether leaving the ticks on on one axis does not hamper the other axes.

Edit the parameters added would create a 2^4 test plots in terms of the combinations; I opted for specific tests that are a bit more complex but are quicker to generate while still testing all the properties.

[cvanelteren]

Will fail on added test.

[codecov]

Codecov Report

Attention: Patch coverage is 85.88235% with 12 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
ultraplot/axes/geo.py	81.81%	7 Missing and 5 partials ⚠️

📢 Thoughts on this report? Let us know!

[cvanelteren]

Note to self, we may want to add this feature to the docs. Done

[cvanelteren]

Removed some scaling around, but should be good now @beckermr

[beckermr]

Let's wait until we resolve the discussion of how to detect projections that are "flat." An allow list won't scale.

[cvanelteren]

We can do the names as fallback and check with direct computation. I will draft something up.

[cvanelteren]

The fallback is now the names while the projection is tested if the slopes are 90 deg.

[beckermr]

See my comments above.

[cvanelteren]

todo: rm boolean logic and add unit conversion if string.

[cvanelteren]

Looks good now! @beckermr. I will rebase if approved.

[cvanelteren]

It is a little tricky to test the untested and partial parts raised by codecov. The main issue is that the code itself does not allow to objects in such a way to these high level function that would create the problems. We could either provide tests for the low level functions, leave them as is, or remove the additional logic that would safeguard against edge cases. I am leaning towards the second option.

Edit: to clarify. The function filter wrong settings out before it can reach a point where it will cause issues. For example, I can create a custom projection without a known name and with a custom projection but it would then be recreated by the functions on format.

[cvanelteren]

To add fuel to the fire I also just noticed that there is _proj_non_rectangular which also performs a name check.

I can attempt to modify the projection functions directly using a cartopy class, but the name property is read only -- making testing the latter harder. Basemap has similar saveguards for the names.

[beckermr]

A few more items.