Changesets for proposals

[jace]

Proposals are similar to GitHub issues in that:

1. They represent a proposal to do something,
2. And then there is a discussion on the proposal.

The second aspect introduces a timeline of changes, because the discussion will and should change the proposal. Funnel's implementation neglects the timeline. We always only know the current state. We could borrow from GitHub here and restructure proposals.

1. A Proposal object exists, representing the current state of the proposal (this is how it currently works).

2. A new ProposalChangeset model records a diff of what is changed. Every proposal has a root changeset, and each revises the previous (the implementation of this changeset will require some thinking, since it's unclear if linearity comes from the timestamp or a previous revision id).

3. A ProposalComment model replaces CommentSet and Comment. The new comment model is flat, but optionally can identify another comment that it is replying to. Comments and changesets are interwoven into a timeline. When a comment is deleted, its content is removed but the shell remains, so that the timeline is preserved.

4. Labels present a problem as they are first class database objects in the project. The application and removal of labels from a proposal must be recorded in a timeline. However, if the label is deleted from a project, it's application on a proposal is also deleted, but the changeset cannot record this as it no longer has a reference object. It will instead need to record the label as text. Labels will similarly get messy when a proposal is moved between projects. We can get around this if we always treat labels as plain text (the way talk type and technical level are currently recorded), using the first class database object (matched by text) only to determine the colour code and icon.

[jace]

We can also solve for labels by making them immutable. A label can be archived, but not edited or deleted. Renaming a label will effectively mean:

1. A new label is created.
2. The old label is removed and the new label is applied on all proposals, in a single changeset.
3. The old label is archived.

[jace]

This will affect the current labels implementation in #313 and #392.

[jace]

Since changesets are oral descriptions of what has happened – meaning they are not linked to database objects that could disappear – they can be implemented via the commenting system itself, by (a) adding a flag to the comment model to differentiate between text and data, and (b) adding a JSON payload containing changes (to be rendered via a payload processor view). Text payloads are not suitable as they can't be localized.