Initial discussion on Pyresample 2.0

This issue is meant to present ideas and things to think about before the Spring 2019 PCW. This will start out as a sort of braindump, but I'll try to structure it a little. Things to consider, possible breaking changes, etc:

1. Main features to include

1. Geometry Definitions (areas, swaths, etc)
2. Resampling functions (nearest neighbor, bilinear, EWA, etc)

2. Interfaces to consider

1. Limit core geometry definitions to AreaDefinition (or rename to GridDefinition?) and SwathDefinition. Area's are understood to be projected and uniformly spaced. Swaths are lon/lat are we assume they are not evenly spaced.
2. Allow swaths to hold additional metadata like limb/edge resolution, nadir resolution, bbox (g-ring?), etc. Not sure it matters, but should there be an optional keyword argument for what "type" of lat/lon points these are (geodetic versus geocentric, etc)?
3. Altitude/elevation coordinates? Unless we start supporting proper 3D interpolation (assuming that level N can be affected by values on levels N-1 and N+1) I don't think we need to handle this but I'm bringing it up anyway.
4. Xarray accessor to allow for my_data_arr.pyresample.resample(area_def). See geoxarray project for possible overlap.
5. Resampler objects to allow for resampler = NearestResampler(source_area, target_area); resampler(my_data).
6. Provide a simplified resampling interface for one-shot resampling where you provide your data, source area, target_area, and kwargs. The function call would create the appropriate resampler object and handle all of the other stuff. This is the non-cache interface.
7. Require pyproj 2.0+ and use pyproj CRS objects internally. Allow for WKT, PROJ strings, etc.

3. Questions

1. Should SwathDefinitions allow for x/y coordinates that are non-uniform but are on a projected space?
2. What does an AreaDefinition need to be properly/fully defined. Does it only accept a CRS object from pyproj? Does it accept PROJ.4 strings, WKT, and CRS objects? We considered dropping things like "proj_id" but in WKT something like this may be necessary or useful to fully describe the CRS.

Comment any additional ideas or concerns.

No files, tests, or implementation entry points are named. Start by reviewing the proposed geometry definitions, resampler interfaces, pyproj CRS handling, and the listed questions; the work is not complete until the 2.0 scope and decisions are agreed.