FIX: Change PlateCarree Vector Handling

[greglucas]

Update of #1920 (Apparently you can't reopen a closed PR when you've force-pushed to your branch)

If a PlateCarree projection is used for transforming vectors, users likely have their data in longitude/latitude for the locations and the measurement of the field is in geographic North/South (NOT PlateCarree coordinates). To handle this situation with PlateCarree requires an additional scaling by the latitude of the point.

This requires some additional care for handling points near the pole when applying the scaling (due to near-zero values in the cos(lat) scaling). To handle this, we can apply an artificial cutoff within the vector transform of 89.99, which pushes the point of the vector transforms ever so slightly away from the pole. This cutoff does not get propagated up to the x/y locations of the plot, only the points that are used within the vector transform. Additionally, this also indicates that the current vector directions we are testing against are incorrect, where I think I've convinced myself this new version is correct with what I would expect.

I haven't updated the image tests yet, as I thought it might be easiest to leave them failing for now so people can download the diff and see what they look like. Overall, I think this is an improvement, but it comes at the cost of special-casing the PlateCarree transform. We could also add a keyword argument 'latlon=True', or something similar to keep this as an opt-in and not change any of the old behavior.

Note

If we want to generalize this to all projections, perhaps we should try to leverage pyproj's get_factors() and apply the meridional and parallel scale factors to the u/v components. https://pyproj4.github.io/pyproj/stable/api/proj.html#pyproj.Proj.get_factors

closes #1179

[lgolston]

This seems like a good solution given this feature has been requested multiple times, and represents a common use case. It is too bad you didn't already get some feedback!

I ran some test cases for Antarctica (similar to what was presented by @jabadge in #1179) and the behavior looks right. The pole cutoff of 89.99 was plenty conservative in this test.

The only thing I didn't initially realize that the section in step 4 starting if isinstance(self, PlateCarree): doesn't apply when transforming from lat-lon to a different projection, and have not tested that part.