refactoring the schema to provide always "valid" models

there has been a lot of discussion in relation to how to accept and serve valid models. let's use this issue to discuss details:

1. separating type validation versus requirement validation. we often mix these as a result of our tools. Let's start with everything being Optional. this will allow us to do type validation (for most part, see next point). and we can do requirement validation as a function/method that can be customized for different needs, similar to the nwb inspector.
2. there are several asynchronous processes in the system (e.g., generating a valid checksum). till the checksum is generated, the server should indicate something about state/stage of operation. this is an enumeration that we can come up with that is semantically meaningful to the end user. would require polling on draft dandisets, but that's ok.
3. python uses `None` as a catch all. and different systems encode missing versus explicit use of `None` in different ways. we should become consistent and i suggest we come up with a plan that distinguishes `None` from `MISSING` and further subcategorize `MISSING` with more specific elements from some ontology. this will also allow for valid dandisets where we impose new requirements, but someone could say the information was `MISSING`, `NOT ACQUIRED`, `RESTRICTED`. allowing us to encode sensitive fields as well.

@jwodder @yarikoptic @AlmightyYakob @CodyCBakerPhD @candleindark

related issues:
- #127
- #182