Better handling of anti-meridian cases

Sorry for not following the template, but I'm not sure this fits.

Currently the DynamicAreaDefinition.freeze method has an antimeridian_mode keyword argument that I added for handling cases where the provided lon/lats cross the anti-meridian (-180/180 in lonlat space). This kwarg can be:

1 .modify_crs (default): Add a +pm=180 to shift the prime meridian of the projection to 180 degrees. This means the extents surround 0 instead of being discontinuous over -180/180. See downsides below.
2. modify_extents: Mess with extents of lon/lat projections so the longitudes are 0-360 instead of a -180-180 range. See downsides below.
3. global_extents: Change the extents to be the entire globe. Theoretically if resampling handling this properly you get a full globe with the input data split into two pieces.

The modify_crs is problematic because many tools don't respect +pm=180 (see https://proj.org/en/9.5/usage/projections.html#prime-meridian). The modify_extents is a problem because it seems some (all?) of our resamplers can't handle longitudes outside the -180-180 range either deliberately filtering them as invalid (kdtree nearest neighbor does this) or suffering from PROJ transformation automatically wrapping longitudes to the -180-180 range.

For these reasons I propose a few important changes:

1. Deprecate modify_exents and combine it with modify_crs, but at the same time change modify_crs to use +lon_wrap=180 instead of +pm=180. See https://proj.org/en/9.5/usage/projections.html#longitude-wrapping which I think is what we normally want anyway.
2. Change kdtree resamplers to only filter lon/lats >=1e30 instead of doing the full -180/180 and -90/90 validation. This would allow PROJ to handle the wrapping.
3. Update EWA resampler to use pyproj's Transformer class and be more explicit about convert lon/lats to the target projection. This should hopefully gracefully use the +lon_wrap=180 which I don't think is working right now.

Questions:

• What does get_lonlats for an area return that has +lon_wrap=180. Should it return 0-360 or -180/180 even though they wouldn't be contiguous? In the past I think we updated this method to assert that lon/lats are always -180/180.
• Edit: Does +pm=180 get us anything (is it useful to us or our users) that +lon_wrap=180 doesn't?