Handle LinkML migration issue of `pydantic2linkml: Impossible to generate slot usage entry for the`

**Update:** The wording of these errors now start with "Cannot express in a slot_usage entry" after `pydantic2linkml` allows partial `slot_usage` entry generation through https://github.com/dandi/pydantic2linkml/pull/71.

pydantic2link has the complains about not able to generate some slot usage entries in generation of some class definitions

such as in the translation of the `Dandiset` class

## Stats of such complains

Total: 54 count
Ones about the `schemaKey` usage slots at different class defintions: 41 counts

## Cause
pydantic2link unable to generate the usage slot cause by the fact that LinkML schema are [monotonic](https://linkml.io/linkml/schemas/slots.html#slot-usage). Restrictions from a slot usage definition are only additive and can not override the restrictions in the corresponding slot definition.

## TODOs:
- [ ] Come up with a solution to handle each of these complains in the generated LinkML schema
- [ ] The ones about `schemaKey` should be able to be handled the same way (do these first)
- [x] make the `schemaKey` slot be a type designator (using the _merge.yaml)
- [x] remove the `ifabsent` value in the `schemaKey` slot (this value is not relevant in a type designator; using the he _merge.yaml))
- [x] remove all the existing notes of `Impossible to generate slot usage entry for the SchemaKey` appended by pydantic2linkml
- [x] make `schemaKey` required (using the `_merge.yaml`). Doing this ensure new data coming in have the `schemaKey` field.
- [x] note: if `_merge.yaml` was merged "first" while processing subclasses, and if default value differs from the class name - we wanted to add `notes:` about that divergence
- [x] workaround: add manually to `_merge.yaml` file those notes for all those classes where we overload `schemaKey` with the value that is not the same as class name
- [x] remove the `MANUAL_NOTE` once https://github.com/dandi/dandi-schema/pull/419 is merged for they are no longer needed.
- [x] Figure out **why** or **what for** we had schemaKey 'Dandiset' for `PublishedDandiset` and so on
- [ ] ~~check what class loading of a published dandiset manifest record results in (I guess should be `PublishedDandiset`)~~
- [x] check with @dandi/dandi-archive people how schemaKey is used in frontend (e.g. meditor) and whether it must remain e.g. "Dandiset" for "PublishedDandiset"
- [x] dandi-archive's frontend doesn't use `PublishedDandiset`. It uses `Dandiset`. Additionally, the `schemaKey` values of `PublishedDandiset` and ``Dandiset` are both `"Dandiset"`