Rethink preference display for address-based preferences and list-based preferences

Currently, preference inheritance in Mailman is powerful, but perhaps non-intuitive to the user.

1. If you have membership (list) based preferences set, those are taken into account first
2. then email address based preferences
3. then the user's global settings
4. then the system's global defaults

Unfortunately, this means when you grab preference data, you often get nothing, and we want to display to the user, somehow, that those preferences have not been set.

Currently we're doing two things:

1. On the global preferences tab, the first time the user looks at it it loads all the defaults and sets them for the user, so the form displays the user settings and the user has settings for every single option.
2. On address-based and list-based preferences tabs, we show a django form with radio buttons, and if the user hasn't set something then the options will indeed appear un-set. This works if you know what's going on, and the page tries to guide the user to enlightenment, but I suspect we can do better.

I think what we want is for the address-based and list-based preferences to somehow show the value of the inherited preference and gives the user a way to go back to that default (i.e. clear the specific preference) if they so desire, but I'm not sure how to do this in a way that is clear right now.

Please discuss proposed solutions in this bug before spending too much time writing code, since we're not sure what we want yet.