Port Geodesic routines to use pyproj

[greglucas]

With #1808, we are using pyproj in trace.pyx, but it would be good to use pyproj for all PROJ interfaces. So, we will need to convert the Geodesic routines to use pyproj as well. (Some are in geodesic.pyx and others are in trace.pyx)

[QuLogic]

See QuLogic@d109aac for an attempt to convert trace.pyx to pyproj.

The projection benchmarks increase by about 50% doing so (~2s to ~3s), which seems too large. I'm not sure if it's due to pyproj not supporting the geod_line API or because we have to flip from Cython to Python to C very often during the bisection.

[greglucas]

We just took a big hit in speed in the linear case to move to pyproj. I actually think that 50% slower in the spherical interpolation is worth it if we can completely drop the PROJ installation dependency (relying on pyproj for everything). That commit looks appealing from my perspective.

[dopplershift]

I'd want to know for sure the performance hit based on some real-world cases. In general, though reducing our maintenance and build overhead is worth quite a lot to me.

[QuLogic]

This is based on our asv benchmarks:

As you can see all projections are slower by roughly the same ratio. I only benchmarked the last 20 or so commits, so I don't know what effect the pyproj change had.

These tests all check project_linear on the OCEAN feature and 50m scale.

[QuLogic]

You can see at https://qulogic.github.io/cartopy-bench/ in the geodesic benchmarks how the conversion to pyproj in #1857 slowed down geodesics.

Additionally, the last commit here https://qulogic.github.io/cartopy-bench/#project_linear.Suite.time_project_linear shows what happens when trace.pyx is also converted to geodesics (the sixth- through second-last commit are for #805).

[greglucas]

@QuLogic, I just checked out your branch and tried to profile a couple of examples that would use the geodesic routines (tissot and effects_of_the_ellipse) in a real example. These showed very minimal increases in overall runtime, maybe 10% or so (hard to tell on these fast examples though). There are a lot more calls to pyproj's geod.fwd due to the SphericalInterpolator, but even that isn't super slow.

I think that branch would be a good addition to Cartopy to get rid of all of our PROJ dependencies and push that completely into pyproj (which has wheels!). In particular, it would remove the ambiguity over minimum PROJ versions on our end.

[greglucas]

This was added in #2069