threaded discussion BenW changes

This MR covers the threaded discussion work, #809 (closed), excluding getting the isRequired validation working; and part of the selective publishing #931 (closed).

I want to get this into review even though selective publishing is not feature complete.

This gets selective publishing as far as being able to select fields and comments, and this selection is stored in the DB. The selection is modifiable. It doesn't yet do anything about the server-side logic of publishing. The next step will be to read the selections during publishing and use them to choose what data to publish.

The data structure for threaded discussions is as follows:

• A ThreadedDiscussion has 0..n threads
• A Thread has 0..n comments
• A Comment has 0..n commentVersions and 0..n pendingVersions
• A CommentVersion or PendingVersion contains an author and a rich-text comment.

We support multiple threads per discussion for future-proofing, since we expect a future requirement for reviewers to create multiple threads to deal with different aspects of the review. But currently there will only ever be exactly one thread per discussion.

commentVersions are a history of all submitted changes to the comment, including who submitted that change. The current text of the Comment is whatever is contained in the most recent commentVersion.

pendingVersions are unsubmitted new comments that are still in the process of being written, or edits to existing comments that are not yet submitted. These are saved to prevent data loss, since comments are expected to be long and take a long time to compose. There should be no more than one pending version per user for any given comment.

When a threaded discussion is served to the client via graphql, the server strips out all pendingVersions except those belonging to the current user. There is thus never more than one pending version delivered per comment.