* `POST /api.ee/serialization/serialize/data-model` endpoint

* Sort namespaces

* Don't use `tru` for endpoint params validation

* Add `serdes-descendants` for "containment" to serialize a subtree

This allows naming eg. a Collection and will recursively serialize: all
dashboards, cards and dashcards it contains directly, plus all child
collections and everything they contain.

Currently this words on Collection, Dashboard, DashboardCard, and Card.

* lint

* Switch to plural `extract-subtrees` with a list of `targets`

This supports serialization of only Collections and Settings so far, but
it demonstrates the design of the new serialization system.

`metabase.models.serialization.base` defines the multimethods, which
are to be implemented by all the exported models eventually.
The actual serialization code that drives the larger process is in
`metabase_enterprise.serialization.v2.extract` and `.merge`, since
serialization is an enterprise feature.

The design calls for two matching phases on each side:
- Serialization is extract + store;
- Deserialization is ingest + load.

Extract and load deal with vanilla Clojure maps with a `serdes/meta` key
giving common details; they deliberately know nothing about files.

Store and ingest deal with the storage medium and the process of
listing and reading a stored export.

Laziness is retained: the `load` process ingests full details on demand,
so only the metadata of the importing database needs to fit in memory.