Refactor the wiki node revision system from one node for each date to all dates in one node

The current system is unnecessarily complicated for content authors to deal with, and also makes it more difficult to implement things like advanced editorial workflows as described in #11 (closed). Most of our pages don't differ very much and what changes do exist can be reasonably implemented as something marked up within a single node's content, where editors can define blocks that are only to be shown for a certain date range.

Implementation

Paragraphs

We could implement a paragraph type that can have multiple slots, each assigned a date range by the editors, which can group nested paragraphs as only rendered for that date range. See omnipedia-content#13.

Markup

Something like a new <date start="xxx end=""xxx"> element seems like the best way to handle this, where it wraps content (paragraphs, media, etc.) and that content is only shown for the date range specified; if either the start or end dates are omitted, that will indicate the content is to be shown from the first date or to the last date, respectively.

Displaying revisions

Since we can no longer expect one wiki node to equal one defined date, this brings up the question of how to display each revision in a cacheable way that has a meaningful path like the current wiki/<year>/<month>/<day>/<title> paths; given the number of dates, it would be really cumbersome to set up individual view modes for every date, even though that would technically work; a better solution is probably to implement a custom route and controller to display a given wiki node, with the date parts in the URL now becoming real arguments; implementing a custom controller like this would also be a step closer to implementing a reliable render warmer as described in omnipedia-warmer#1.