Preferences UI rewrite.

Preferences UI rewrite.

Goals of the rewrite:
1. Make ALL preference page display across ALL applications handled by a
single point: the horde services preference page. This means moving all
application specifc preference handling to inside of
Horde_Registry_Application functions. NO page, other than
horde/services/prefs.php, should be using the Horde Prefs UI functions
anymore.
2. Move Horde Prefs UI code out of Prefs package and into the Core
package. UI handling is not something that should be handled by a
library (will eventually move other things out of Prefs too, including
Category Management and Identity code, since this is code that overlays
the Prefs driver in a Horde-specific manner)
3. Simplify the prefs UI configuration. Don't require 'shared' or
'locked' entries (default to false) or 'type' entry (default to
'implicit'). Remove some unneeded types (select). Improve documentation.
4. Handle dynamic population of entries and suppression of prefGroups
and specific preferences in Application::prefsInit(). This code confuses
the prefs.php file.
5. Abstract out some common 'special' preference handlers.  For
example, identical addressbook selection code is used in several
applications (imp, kronolith, whups). Move this code to a prefs UI
widgets class so it can be reused.
6. Convert prefs templates to Horde_Template. As always, I know the
arguments against HT, but the simple fact is that is still the only
time-tested method that we used and it does produce a template file that
is easy to edit. Not to mention that the PHP code polluting the old
include files made these files absolutely unreadable and/or
maintainable.
7. Remove credentials code.  It wasn't being used anywhere in the code (I
believe it used to be a hack for IMP-related auth in Horde 3.x, but
shouldn't be needed anymore due to new authentication code).
8. Other improvements that have escaped my mind since I have been
working on this code for several weeks now...

Reasons for the rewrite:
1. The old Prefs UI code was ancient and a mess.  It was a static file
and globals were used all over the place.  New UI code is OO-based and
allows us to pass the object around, making these like suppression of
groups/prefs, hiding buttons, and current state identification much
easier and cleaner.
2. There is a need to redo the UI itself, especially for dynamic
apps, to allow for a different/better preferences experience. Thus, the
UI will eventually be able to be themed based on the current view type
(dynamic, standard, mobile/minimal). To do this, all UI needs to be
controlled from a single source, rather than disparate scripts.
3. Add ability to mark preferences as 'advanced' so they are not shown
by default.  This is prefereable to the current method of 'locking'
advanced prefs.  Admins may very well want users to be able to change a
pref, but they don't want that pref shown to basic users.