Use PyProj instead of Cartopy for internal coordinate transforms and rename crs coordinate

[jthielen]

Description Of Changes

Implements the changes discussed in #1455 (comment). Part of this was changing the API for lat_lon_grid_deltas to take the PyProj Geod directly rather than by constructor kwargs (makes it easier to handle from grid_deltas_from_dataarray, which extracts the Geod from the PyProj CRS).

Marking as draft/work-in-progress for now since the following have yet to be done:

• Update azimuth_range_to_lat_lon and any other Geod uses to take geod arg rather than kwargs to construct new Geod
• Make pyproj >= 2.2 a required dependency (unmodified as of now)
• Check if pyproj 3.0.0 breaks any APIs that would necessitate a forward-looking pin
• Diagnose the failure of 4D kinematics tests (want to know what changed exactly with grid delta calculations, and see if we were in error before and this fixes it, or if something broke with update)
• Add tests of new pyproj helper methods

If someone wanted to take these items on to speed up the process, that would be great! Otherwise, I'll loop back to this after the xarray stuff for 1.0.

Checklist

• Closes Use PyProj instead of CartoPy for calculations #1455, half of parse_cf issues with NCEP precip data #1459
• Tests added
• Fully documented

[jthielen]

Just fixed up the rebase of this on latest master after the changes of #1490, but the todo list above remains.

[dopplershift]

I looked at the list on Python 3, and API wise I think we'll be fine. However, they are dropping older versions of PROJ, and doing enough that I think the right approach is to make our PyProj dependency right now >=2.2,<3.0. We have the testing infrastructure that will make it easy to evaluate how 3 works for us, but I don't think there's any need to rush into support for PyProj 3.0.

[dopplershift]

The reason for the test failures is that before for...CartoPy reasons...we were using PlateCarree for lat/lon projections--which doesn't support globes. Thus, when converting that to a PyProj Geod, we ended up using the default (WGS84). Now by using PyProj directly, we create a correct Geod instance from the metadata (for the tests this is actually a sphere with a particular radius). For our test dataset, the difference is ~1km on a ~350km spacing.

Before updating all the test values, I was able to make the tests pass by hacking the test metadata to specify a WGS84 spheroid, so that's clearly the issue.

Further evidence that shifting over to using PyProj directly for calcs is a good thing to do.

[dopplershift]

Bumping our minimum pyproj to 2.3 was enough to make tests pass for me locally. Assuming that holds on CI, let's just go with that (released Aug 2019) rather than trying to do any special work-arounds.

[dcamron]

I like these changes, and didn't find any other issues myself!