Refactor spatial search to use modern Solr options

Solr documentation: https://solr.apache.org/guide/8_11/spatial-search.html

The Postgis search option will be dropped.

Of the other two remaining ones:

* `solr` is based on bounding boxes, both in the geometries indexed and and the input query geometries, and it doesn't actually use any spatial library underneath, just [math operations](https://github.com/ckan/ckanext-spatial/blob/cd6667dc321b893290bf3808b6a331011f1d0323/ckanext/spatial/plugin/__init__.py#L290) performed on [values indexed](https://github.com/ckan/ckanext-spatial/blob/master/ckanext/spatial/plugin/__init__.py#L205-L219). This could be replaced by the [`BBoxField`](https://solr.apache.org/guide/8_11/spatial-search.html#bboxfield) which provides the same functionality in Solr
* `solr-spatial-field` is based on actual spatial operations powered by JTS (or Geo3D) in Solr, using the `SpatialRecursivePrefixTreeFieldType` or RPT field type. It supports points, polygons and bboxes so we can probably combine both modes of operation.

Things to explore:
* RPT might require and additional `LatLonPointSpatialField` for sorting (see note in [RPT](https://solr.apache.org/guide/8_11/spatial-search.html#rpt)
* Solr supports WKT for indexing geometries, can we support it in our `spatial` field?
* It would be interesting to provide a mechanism for extensions to index geometries that are not stored in the `spatial` field, eg from a lookup table, to avoid storing big values in the dataset metadata. Maybe this is just a matter of providing a pattern for overriding the `before_dataset_index()` method

A pre-built Docker image will be provided to facilitate the installation and usage, as well to be able to write tests against a spatially enabled version. See https://github.com/ckan/ckan-solr/pull/5