Consider using "geometry" instead of "geography" terminology

[jorisvandenbossche]

This is mostly in context of the discussion in geopandas how to integrate spherely in the geopandas API (as "spherical geometry" vs "geography"): geopandas/geopandas#2769 (comment), although there are also some arguments for spherely itself for doing this.

From the point of view of geopandas, if geopandas decides to stick to "geometry" terminology, it would be nice that the scalar object that is stored in a geometry column would be a spherely.Geometry object instead of a spherely.Geography object (although I also don't think it is a blocker for geopandas).

From the point of view of spherely itself:

• The term "a geography" is a bit strange to describe an actual geometric object. This is not really used elsewhere as far as we know (you certainly see "geographic features" or objects or similar, or more general "geospatial" data/objects). Of course the database world uses the term "geography", but that is mostly used to denote the data type, not the actual objects (e.g. BigQuery says "the GEOGRAPHY data type represents a geometry value or geometry collection.")
• The simple feature standard (and I think s2geogaphy/spherely can be seen as a simple features layer around s2geometry), while being about geographic features, uses the term "geometry" for the objects.
• The s2geometry library itself talks about "geometries" (it does use "geographic" in its documentation, but to refer to "geographic datasets" for which s2 can be used)
• This would also avoid the internal conflict we encountered in eg having a GEOMETRYCOLLECTION entry in the GeographyType enum (I know at some point we first used GeographyCollection)

In practice (based on the current API), I think this is only about the name of the spherely.Geography class (which the user does not actually instantiate directly), the spherely.GeographyType enum and the one spherely.is_geography vectorized function (and in addition documentation and potentially argument naming).

So I think it is still a sizeable change, and of course one that, if we want to do it, we should do sooner rather than later. I personally think it is still possible to do at this stage (especially given that we can just keep those three classes/function available as exact aliases for now)