[Future Spherical Class] Add SExtent

[ghiggi]

This PR adds the SExtent class of the future spherical geometry interface.

• Tests added
• Tests passed
• Passes git diff origin/main **/*py | flake8 --diff

[codecov]

Codecov Report

Merging #466 (b640432) into main (5f53ecd) will increase coverage by 0.02%.
The diff coverage is 94.57%.

❗ Current head b640432 differs from pull request most recent head 485bd48. Consider uploading reports for the commit 485bd48 to get more accurate results

@@            Coverage Diff             @@
##             main     #466      +/-   ##
==========================================
+ Coverage   94.27%   94.29%   +0.02%     
==========================================
  Files          69       74       +5     
  Lines       12394    12929     +535     
==========================================
+ Hits        11685    12192     +507     
- Misses        709      737      +28     

Flag	Coverage Δ
unittests	94.29% <94.57%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
pyresample/future/spherical/extent.py	79.28% <79.28%> (ø)
pyresample/future/spherical/__init__.py	100.00% <100.00%> (ø)
pyresample/test/test_sgeom/__init__.py	100.00% <100.00%> (ø)
pyresample/test/test_sgeom/test_extent.py	100.00% <100.00%> (ø)
pyresample/test/test_sgeom/test_shapely.py	100.00% <100.00%> (ø)
pyresample/_multi_proc.py	83.01% <0.00%> (+1.88%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[coveralls]

Coverage remained the same at 93.823% when pulling b640432 on ghiggi:feature-sextent into 5f53ecd on pytroll:main.

[ghiggi]

@djhoese @mraspaud this is ready for review.
Tomorrow I have faculty meetings, but I can finalize the last details on Friday if you manage to review it tomorrow.
This PR is required for the future SPolygon class PR.

[ghiggi]

Prioritize the review of #465, #473 and #475 first ;)
This will only be needed to speed up the SPolygon computations

[djhoese]

So basically this is to handle all the edge cases of extents that wouldn't make sense to include in a generic Polygon class, right?

[djhoese]

Is there a need or benefit to supporting both of these types of multi-extent inputs?

[ghiggi]

No need. Which one would you suggest to drop?
I would keep the first.

[djhoese]

Sorry, it's been a long time since I've looked at this and I can't quite remember what this class does. So it merges extents (bounding box?) into a single MultiPolygon? The idea being you either have one contiguous extent or you have two extents that "cross" the antimeridian, right? Will there ever be a need for more than two extents?

[ghiggi]

Yes. One could discretize a SPolygon in lot of non-intersecting extents ...
But the main use case is to deal with the antimeridian ...

[djhoese]

I'm not sure what I prefer. Initially I was going to say only use the second one (passing a list), but since the usual case is a single 4-element extent then maybe the first and the third should be the only ways to do it.