Attempt to unify the Geometry support across the backends.

Since downstream the users will need to pass geometries into a library/database to be useful, we might as well stick with wrapping WKB cleanly rather than implement an entire type hierarchy with all the resulting complexity. If we build off the OGC Simple Features for SQL standard then that's what the databases already support and it'll keep working. And WKB supports all the underlying types in 2D/3D/4D/whatever representations.

Plan

1. Create a generic io.debezium.data.Geometry class for planar coordinates. This maps to PostGIS geometry type, MySQLs GEOMETRY, and similarly for other DBs.
2. Create a generic io.debezium.data.Geography class for spherical coordinates. This maps to PostGIS geography, and similarly for MSSQL/Oracle/DB2 (MySQL doesn't support a spherical type).
3. Each generic type would effectively have two attributes carried around per-row – a standard WKB representation of the coordinates (supporting any Simple Features for SQL WKB geometry) and an optional coordinate system identifier (SRID integer).
4. Map MySQLs builtin geometry types to the generic Geometry class.
5. Map PostGIS types to the generic classes for decoderbufs & wal2json backends
6. Leave the existing PostgreSQL builtin geometric types (Point/Polygon/Path/etc) as-is, since they are rarely used. If someone wants to convert them to generic Geometry classes later, that's future work. And they'll keep working for compatibility.
7. The existing MySQL Point class (which is a geometry) will continue until 1.0 for backwards compatibility – it will derive from Geometry, have the WKB+SRID attributes, and additionally the x,y attributes.