Allow specific settings to override permissions

It took me a little while of reading the instructions, scratching my head, reading the code, and then re-reading the instructions before I figured out exactly how this should work. My issue was that even though I protected eMail and password for a specific demo user, the demo user itself could change their own eMail and password. Well, that clearly was not on. Yet to get it to work properly, I had to disable the "Change own password" and "Change own eMail" permissions for all roles of which the demo user was part. Well, that then had impacts on what the demo user could do in my demo system, which defeated the point of having a demo user in the first place. So, after scratching my head a bit, I came up with the following patch to create a "up_self" setting, which fundamentally overrides permissions (and set it as such as the descriptor). That way, I could check off that checkbox, and then permissions would be ignored in the hook_form_alter call, looking just at the protection settings. Works nicely for me, and I can leave permissions as-is for other users.

The patch also includes a couple of changes to #description fields, and not unsetting the password field, but rather changing it with a description to tell the user what is actually going on, as I feel this is better vis-a-vis UI design and not confusing the user.

Finally, just a comment on the architecture of the module itself after having made this patch. In order to get this to work, I had to add a column to the table. Per third normal form, this should not have to be the case, as the value of the attribute (column) here for this instance should depend on "the key, the whole key, and nothing but the key". However, it does also depend on the column name itself. Perhaps a better and more flexible architecture would be to put the table into third-normal form, introduce a second table that is in fact the column names, and make appropriate other changes in the code to get the array of things protected from that second table, perhaps mapped to the form element IDs. That way, it would be extendable later on with just new data. Just a thought...

shawn