I should be able to manage Conversation Preferences better

Summary: The current UX for this sucks, and is tied to the old and dying approach to User Values. It needs to get split off.

This is a small Epic. Here's the outline.

Currently, we have a simple on/off switch, under Advanced, that either gives you all of the Comments in this Space or none. It's too coarse-grained, and it only takes effect when the Space next recycles.

We should have the following Preferences, each separate:

Obviously, the wording displayed should be customized to the page that's being displayed, but that's roughly it.

These should all be simple yes/no checkboxes -- ExactlyOne, not Optional as it currently is, which is confusing as hell.

The preference should get moved out of Advanced, which is simply a holding cell. It should be available directly from the Notifications icon with as few clicks as possible, but initially it'll probably be easiest to set it up with its own page.

In the long run, there should eventually be a multi-tab page for Preferences. This should be an alternate way to get here, but it should continue to be possible to get to this from the Notifications icon, since it's the logical place to look.

Turning on/off Notifications for this page, in particular, should probably be directly off the Notifications icon?

In the new model, the ThingConversationsActor generates the comment and the list of previous authors in this thread, and forwards that on, eventually to the SpaceConversationNotifier. That Notifier will want to become a PersistentActor, which owns the Space-wide Preferences. (Preferences particular to this Page or Thread should live in the ThingConversationsActor itself, so the message to SpaceConversationNotifier will need to contain that information.)

This implies that we need a new "preferences" API pathway. We're currently suborning User Values to this purpose, and it's conceptually elegant, but in practice isn't going to work quite the way we want. In particular, so long as the SpaceConversationNotifier is separate from the actual Thing that owns the User Values, we're going to have the problem where changes don't take effect immediately. The locus of control is wrong.

So we want to come up with a new concept around the APIs, of Preference values. There are probably new entry points in the Client, for fetching / setting Preferences. (Possibly all at once, possibly in separate groups.) Each Preference is a lot like a standard value, and should probably serialize the same ways, but they are gathered up from various Actors -- we probably need a fairly general mechanism in the back end for sweeping in a variety of Preferences from various sources and sending them up, we need identifiers for each one, and we need a mechanism that registers where to send a Preference when it changes.