Add more flexible antimeridian handling to DynamicAreaDefinition

[djhoese]

Problem description

I'm attempting to replace some old code (Polar2Grid) that would take the equivalent of a DynamicAreaDefinition and produce a static AreaDefinition. In my old code I would "help" the user if they tried to "freeze" the dynamic area with data that crossed the anti-meridian of the projection by modifying the projection and extents so the final result covered the data, not the whole projection space and not a partial of the data. Right now this behavior is not possible with DynamicAreaDefinition.freeze.

I'd like to add a keyword argument to control this logic and call it something like antimeridian_mode. This kwarg could be set to 1 of 3 options (4th value None as default). See Expected Output below for examples of what these look like.

1. modify_extents/None: This is what is currently done. The X-axis extents are modified to be the left and right of the data where the right-most side has 360 added to it so xmin->xmax is increasing.
2. modify_projection: Includes modify_extents operations but also does +pm=180 on the PROJ.4 dict. This results in one complete image of the data for simple cases that only stretch the anti-meridian.
3. global_extents: When it is detected that data goes over the poles or antimeridian, the extents are forced to -180/180 longitude.

Thoughts? Concerns?

Expected Output

1. modify_extents:

2. modify_projection:

4. global_extents:

Alternatives/Other Info

I'm not sure if the modify_extents image is cut off and still shows the full image size because of the EWA resampling I'm using or just because that's the way it is supposed to be. ...nope, "nearest" does it too.

I could see using the term "fit" somewhere in the possible keyword values, like "fit_extents" instead of "modify_extents".