[DISCUSS] Whether / How to implement Sedona's GeometryType function (not ST_GeometryType)

`GeometryType` is a function specific to Apache Sedona (not part of PostGIS), not to be confused with `ST_GeometryType`. It's not part of PostGIS. Here's the doc that explains what it does:

Introduction: Returns the type of the geometry as a string. Eg: 'LINESTRING', 'POLYGON', 'MULTIPOINT', etc. This function also indicates if the geometry is measured, by returning a string of the form 'POINTM'.
https://sedona.apache.org/latest/api/sql/Function/#geometrytype

I'll emphasize that it includes the `M` dimension in the output. I'm personally not a fan of this function in the original Sedona, for two reasons.

1. Honestly, it's kinda odd and out-of-place. Why does it include `M`, why not `Z` or `ZM`?
2. It's easy to introduce bugs, if you're not aware that it includes the `M` in the output. It's natural to want to write a condition like this `CASE WHEN GeometryType() = 'POINT' ...`, but this would return `False` for any `POINTM`, which is likely not what the user wants. I've used this function a lot, and I only realized this was the behavior within the last month, which led me to create an [issue](https://github.com/apache/sedona/issues/2389) to remove its use in Geopandas.

Since we're already implementing some different behavior from traditional Sedona to match PostGIS compatibility, I was wondering if we could avoid implementing `GeometryType` the same way. Some options I'd like to propose:
1. Don't implement it at all.
2. Implement a new variation, something like this `GeometryType(geom, dim_code)`, where it can be used in the following way.

```
GeometryType(geom, '') -> POINT
GeometryType(geom, 'Z') -> POINTZ
GeometryType(geom, 'M') -> POINTM
GeometryType(geom, 'ZM') -> POINTZM
```

This fixes both of the points above, by making it explicit that whether a dimension will be included + it supports all variations (z, m, zm) so it no longer feels out-of-place.

No implementation file or test is named. Start by reviewing the linked Sedona GeometryType documentation and issue 2389, then compare the two proposed behaviors; done means recording a decision on whether to omit the function or define its dimension-code behavior.

Written by the indexing model from the issue text.