Update nightshade.py to allow user-defined sub-solar coordinates

[dsheward-astro]

This allows for the specification of the sub solar coordinates directly, rather than calculating them using the date. This increases the usefulness of nightshade to those of us using cartopy for non-Earth bodies.

Rationale

Currently Nightshade produces the shade based off the sub-solar point at a defined time, based on the Earth. As cartopy is used for modelling other solar-system bodies, such as the Moon, which will have differing sub-solar points at a given time, the current use case for Nightshade is exclusive to the Earth. By allowing for user-defined sub-solar coordinates, this use case is extended to any sphere.

Implications

Nightshade is now also useable for Non-Earth bodies

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greglucas]

I think this makes sense in general to be able to use the functionality on different bodies. I am not sure the best approach for providing either a date or a sub-solar point, but this seems reasonable.

You should also add a few tests making sure it is producing the values you expect.

[dopplershift]

Minor nits. Looks like pre-commit is complaining about trailing whitespace (might be the line I pointed out). Feature seems like a nice add.

[lgolston]

The documentation should still be adjusted here (main docstring still says "Shade the darkside of the Earth..."; which is no longer true for Nightshade, but is still true that_solar_position is specific to Earth).

The minor nits were resolved

[greglucas]

@dsheward-astro, would you be able to add a quick test for this? Let me know if you want any pointers for where to add it.

I also see that you added the subsolar point as (lat, lon), is that the order we are wanting all of our public facing conventions to be? In all of our plot functions we generally have (lon, lat) due to the x, y ordering. But this also seems fine and is documented so I don't have a strong preference either way, maybe a +0.1 towards (lon, lat) if I had to choose.

[alexstoken]

While testing this on another planetary body, I found that the class likely needs an option to pass an alternative globe (which would then be passed through to the ccrs.RotatedPole() in order to support non-Earth shades.

rotated_pole = ccrs.RotatedPole(
    pole_latitude=pole_lat,
    pole_longitude=pole_lon,
    central_rotated_longitude=central_lon,
    globe=kwargs.get("globe", None),
)

The shade can then be converted to lonlat as follows (from #2142 (comment))

globe = ccrs.Globe(
    semimajor_axis=BODY_RADIUS_METERS,
    semiminor_axis=BODY_RADIUS_METERS,
    ellipse=None,
)
nightshade = Nightshade(
    refraction=-0.01, sub_solar_point=(ss_lon, ss_lat), globe=globe
)
geom = next(nightshade.geometries())
x, y = np.array(geom.exterior.coords).T

latlon = ccrs.Geodetic(globe)

lons, lats, _ = latlon.transform_points(nightshade.crs, x, y).T
shade = shapely.Polygon([lon, lat] for lon, lat in zip(lons, lats))

And users should be careful with the refraction value for other bodies, as the default only applies to Earth.