POST /assets/identify/ and /dandiset/identify/ endpoints

ATM AFAIK there is no way to figure out in API where (asset, and later dandiset / version) any blob or zarr is located.
So similarly to `POST /blobs/digest/` endpoint which finds blobs given a digest, I would expect to be able to post `blob_id` or `zarr_id` and identify assets.

zarr's ATM have 1-to-1 association to dandisets and their initial path is stored in the `name`, e.g.

```shell
❯ curl --silent -X 'GET' 'https://api.dandiarchive.org/api/zarr/23123eef-62df-46b8-92ae-c2102110977c/' | jq .
{
"name": "sub-I48/ses-SPIM/micr/sub-I48_ses-SPIM_sample-BrocaAreaS04_stain-NeuN_SPIM.ome.zarr",
"dandiset": "000026",
"zarr_id": "23123eef-62df-46b8-92ae-c2102110977c",
"status": "Complete",
"checksum": "126425a9448778bcffff2b62d8deb2d2-16251--29928959601",
"file_count": 16251,
"size": 29928959601
}
```

but even though `dandiset` information is indeed valid ATM, `name` does not necessarily correspond IIRC, hence cannot be relied upon. And later, when we allow for reuse of zarrs across dandisets etc, would not be reliable even to point to the dandiset.

Taking this one level up, later I would like to see `/dandiset/identify/` which could be provided `asset_id` or , ideally, alternatively `blob_id` or `zarr_id` or even checksums so we could avoid chaining of API calls per each request to associate specific files/zarrs to dandisets.

WDYT?

NB I am open to an alternative to `/identify/` name.

Start by reviewing the existing POST /blobs/digest/ endpoint and the asset, dandiset, blob, and zarr API entry points described in the issue. Clarify which identifiers and relationships the proposed identify endpoints must support, settle the endpoint naming and response shape, and confirm that the agreed lookup behavior covers current and future zarr reuse.

Written by the indexing model from the issue text.