Fix EZP-23129: sorting by field filters the result set

This PR resolves issue https://jira.ez.no/browse/EZP-23129

This fixes filtering of the result set by Field sort clauses (MapLocationDistance included).
Sort clauses provide ContentType and FieldDefinition identifiers, intended to pin the correct field target, which were used to join with `ezcontentclass` and `ezcontentclass_attribute` tables.

This is changed by introduction of the field map, which provides mapping of ContentType and FieldDefinition identifiers to the FieldDefinition ID, which is available in `ezcontentobject_attribute.contentclassattribute_id` and is used to `LEFT JOIN` `ezcontentobject` with `ezcontentobject_attribute`. This in effect fixes filtering behaviour.

Field map is implemented in ContentType gateway. Because of circular dependency ATM it is not possible to implement it in ContentType handler with Stash caching. Instead of implementing Stash cache on ContentType gateway now, I propose to fix this with refactoring search implementations on SPI change where Search APIs were moved out of Persistence namespace. At that point it should be possible to unify it with requirements of other search implementations (see https://github.com/ezsystems/ezpublish-kernel/pull/1046).

New non-filtering behaviour of sort clauses exposed different `null` value handling in supported DBMS systems. To account for this, Field sort clause handler now has two additional sort fields, containing `NOT IS NULL sort_column` expression that is used to ensure consistent behaviour. `null` values will always be sorted last. This is different from previous behaviour (first ascending and last descending with SQLite and MySQL and vice-versa with Postgres), and same as Elasticsearch behaves.

#### Additional fixes

* consistent `null` value sorting (described above)
* a bug in storage search tests where total count was not asserted, hiding missing search hit
* multiple minor cleanups