Invalid SRID passed to SQLAlchemy

When using pygeofilter on top of a Postgis table with EPSG:4269 (NAD83), requires we explicitly set the geometry CRS (as implemented in https://github.com/geopython/pygeofilter/issues/66) to something other than EPSG:4269. I am unable to run a query because pygeofilter incorrectly extracts the [SRID from the CRS URN](https://github.com/geopython/pygeofilter/blob/8baf30f15b93d39a91d25183299ac0e541ed3c57/pygeofilter/backends/sqlalchemy/filters.py#L20-L29). Producing the following error:

```text
sqlalchemy.exc.InternalError: (psycopg2.errors.InternalError_) parse error - invalid geometry
HINT: "SR" <-- parse error at position 2 within geometry
[SQL: SELECT count(*) AS count_1
FROM (SELECT ..., wmadata.catchmentsp.the_geom AS wmadata_catchmentsp_the_geom
FROM wmadata.catchmentsp
WHERE ST_Intersects(wmadata.catchmentsp.the_geom, ST_GeomFromEWKT(%(ST_GeomFromEWKT_1)s))) AS anon_1]
[parameters: {'ST_GeomFromEWKT_1': 'SRID=CRS83;POINT (-69.39999969709005 46.69999049530215)'}]
```

As noted in https://github.com/geopython/pygeoapi/issues/2102 and https://github.com/geopython/pygeoapi/issues/2010, pyproj respects [axis ordering for CRS objects](https://proj.org/en/stable/faq.html#why-is-the-axis-ordering-in-proj-not-consistent), requiring explicit distinction between axis order in https://www.opengis.net/def/crs/OGC/1.3/CRS83 and https://www.opengis.net/def/crs/EPSG/0/4326. This breaks down when Postgis, only offers EPSG codes in `spatial_ref_sys` and requires SRID entries to be integers - requiring both the aforementioned CRS definitions to share the SRID 4326 regardless of axis order.

So long as [SFSQL](https://www.ogc.org/standards/sfs/) uses an integer SRID as its primary key to parse SRID in EWKT, is there a way to correctly set an SRID in pygeofilter? To functionally handle this, I have implemented [get_srid](https://github.com/geopython/pygeoapi/blob/master/pygeoapi/crs.py#L86-L87) which degrades the CRS object to a proj4 string which allows extracting the correct EPSG SRID. This allows the correct transformations to exist while executing valid spatial SQL.

cc: @dblodgett-usgs