Fixes#3315 by moving the manipulation of the filter widget scopes to the controller event method instead of before any part of the controller constructor method is run.
This builds on 4fd1ca824f by switching from a two tier approach to permissions (superusers and regular users), to a three tier approach (superusers (developer), second-in-command (clients with manage_users permissions), and regular users). If support for a four tier approach is necessary (Superuser, Franchise Owner, Franchise Business Manager, Franchise Staff as an example), then it can be implemented simply by adding a flag to roles that would prevent anyone except for a superuser from assigning that role.
The specific changes made by this commit is to support users with the manage_users permission (but who are not superusers) to be able to assign roles to other users and improvements to the sanctity of the superuser itself. Non-superusers can no longer see or edit superusers in the backend (that was previously poorly handled as a non-superuser with manage_users could take over a superuser account since they could modify that account willy-nilly), and the is_superuser filter is accordingly removed as well.
These are roles defined by a special API code, once a system role code is detected, the role becomes locked and its permissions are sourced from the AuthManager. All permissions are granted to system roles by default, unless otherwise specified. This should make it easier to create client accounts as "Publishers", hiding developer tools like the CMS and Builder plugins by default.
If an admin user has permission to manage other users, they are
able to set others as superuser, or even create their own
superuser account. That's not really what we want.
Create a My Settings page, now linked when clicking a User
Create backend preferences form for setting locale
Dropdown options now support an image or icon in their options
