Need to provide support for different "instances" of DANDI archive

ATM
```
id: DANDI:000018/draft
identifier: DANDI:000018
```
on both staging instance AND on deployed for completely disconnected dandisets. I have committed a "crime" and with my glorious admin powers uploaded some test file to the main deployment instance instead of the staging (not a bigger -- this dandiset is empty on deployment) since forgot to add instance I want to upload to.

I think:
- staging instance should acquire its own prefix, such as `DANDI-STAGING` so any new dandiset created on staging would get that new identifier
- schema should allow for having those few (+ for tests etc) to start with explicitly listed prefixes, but eventually we might make it more of a schema "parametrization" somehow e.g. via env var (but see #67 for DANDI_ALLOW_LOCALHOST_URLS - so may be some "better" way)
- `dandischema` model for the *Dandiset should gain some `sameAs` or alike to provide alternative `identifier`s (if not `id`s) to allow for mapping
- `dandi-cli` should default to the instance to interact with corresponding prefix, and allowed to be overridden -- but then consult the `sameAs` for possible mapping to another "identifier" on the other instance
- `dandi-api` instance should be provided prefix to be used (so `DANDI` for deployment, `DANDI-STAGING` for staging)
- we rely on `DJANGO_DANDI_WEB_APP_URL` env var to further restrict validation of some URLs. It should be somehow separated out/added on top per each instance. https://github.com/dandi/dandi-schema/issues/274

This might become also relevant for orchestrating data interactions for embargoed datasets, if we would allow for some kind of a hybrid, where some prior versions might be made public and subsequent embargoed/private and we have separate DANDI archives for public/private.