"Getting to a draft DEP" process should be simplified

I would like to see the barrier to merging a draft DEP be lowered. In particular:
- A reference implementation should not be expected, but we could mention for example some public API designs would be advisable. I understand this increases the likelihood that the DEP may not be completely resolvable with the patterns discussed, but in practice they will change anyway. A decent discussion of the problem and the proposed architecture of the solution should be sufficient to get a general consensus from the technical board as to whether the idea is worth pursuing.
- A shepherd should be recommended but the implementation team should not be necessary. This allows us to potentially source an implementation team using DSF money or direct sponsorship of a DEP, but that it has already reached a general consensus of "we want to see this area explored and believe in the rough plan".
- We should require all DEPs to be peer reviewed to reach draft status, not give the core team a bye.
- We should ensure that there is a clean process for evolving a draft DEP after it has been merged as people want to work on it.

Comments welcome! I can probably look at drafting some changes to [DEP0001](https://github.com/django/deps/blob/master/final/0001-dep-process.rst). In particular the sections around the [DEP submission workflow](https://github.com/django/deps/blob/master/final/0001-dep-process.rst#dep-submission-workflow) and [submitting the draft](https://github.com/django/deps/blob/master/final/0001-dep-process.rst#submitting-the-draft) need some work.