Comment moderation variations

[wrose504]

We want to support moderation of comments (and likely posts): currently it is possible to edit comments, but there are no easy ways to replace or hide comments in a way that requires a click-through.

This PR adds a moderation_type to comments with the intent that moderation actions can be thought of similarly to replies to comments, in that they are part of the overall conversation and can themselves be moderated or revised. The difference to regular replies is in how these comments affect the rendering of the original comment. The different effects are captured in the ModerationTypeEnum:

• blur - the original comment appears blurred out, optionally with a message overlaid, and clicking it will reveal the blurred comment underneath. The rendered HTML contains the full comment - the blurring just affects the client-side visibility.
• comment - the moderator reply shows as other replies would appear, but has a special border or other appearance indicators to show that it is a moderator acting in their capacity as a moderator, not just as a community member.
• edit - the moderator combines an edit of the original comment body with their own explanatory message that may be shown underneath the original comment.
• remove - the moderator completely removes the comment from display and rendering in the HTML, without providing any replacement.
• replace - the moderator completely removes the original comment body from display and rendering in the HTML, and replaces it's original position with a moderator comment.
• wrap - the moderator hides the original comment behind a disclosure arrow (details element) that can be toggled to show/hide the original comment. The original comment is still available in the HTML.

To make some of these changes have the intended effect, i.e. that removed / replaced comment bodies are not even rendered to the HTML, and to also avoid shenanigans where clients modify backend state in unexpected ways, this PR includes a lot of changes to the attributes actually round-tripped to the client with Livewire. We now mostly just send the comment id, which is marked as #[Locked], and is used to refetch the comment from the database, rather than trusting the snapshot returned from the client. This also reduces some of the duplication in wire:snapshot attributes.

This PR builds on the comment-flagging branch from #60: here is a diff against that branch.

Mini demo!

[csebianlander]

I've gone ahead and merged this.

Can/should/do we set up a "default" user with moderator privileges that would make it more straightforward to road-test these changes in the staging environment?

[wrose504]

Yes! I thought there might be some already that I don't know about, but we can add some!

We could set up some accounts with known passwords, or for specific emails, and then they could use a password reset.

[csebianlander]

let's double back with kirk on this once he's back in the saddle -- we do have a dummy "guest" account, and could maybe do a similar dummy "moderator" account with a default password we keep semi-private via the discord?