Controllers (part ...)

Another controllers PR for your attention. Its main purpose is addition of a base class for controllers.
* introduction of an abstract base class for all controlers, [Action_Controller](https://github.com/norv/elkarte/blob/6a90c1eb17878edfcbbb109f8692d9ae473cbb01/sources/Action.controller.php). It simply declares action_index() and pre_dispatch(), methods that many may have already. (Almost) all controllers now extend Action_Controller.
* made classes those who were not yet. Such as: Profile controllers (several of them), Xml, moderation iirc, etc.
* reworked some ModerationCenter and around it; also methods/functions in Profile classes.
* Xml controller had two 'types' of functions, those for previews, and random other xmlhttp calls. I split Xml controller into two, Xmlpreview and Xml. (with the obvious roles)
* some bug fixes; small tweaks like method visibility.
* moved to subs the database-working functions which serve lists, but created list_() callbacks for lists in controllers.

Please note on this detail on createList() callbacks: list_ callbacks (i.e. list_getWarnedUsersCount or so) serve the controller which creates the list. But, they work with the database to get their data. I made list_ callback methods, in controllers, to be used by their list creation code; and, moved the actual database work in functions in subs. Please see: https://github.com/norv/elkarte/blob/6a90c1eb17878edfcbbb109f8692d9ae473cbb01/sources/controllers/ModerationCenter.controller.php#L1457 or https://github.com/norv/elkarte/commit/6a90c1eb17878edfcbbb109f8692d9ae473cbb01#L0R1560.
The list_ methods will call the subs function to get the data, eventually passing them params instead of globals. IMO, the least advantage is that watchUsersCount() etc, can be cached, tweaked, and reused, from subs, as expected (it's watched users count, a plain information), without being at all tied to some particular lists (those just use them too).

Please note on Action_Controller: action_index() is an abstract method. So, it makes official (lol) that every controller has an action_index() to begin with. Most already did, anyway (or had something as default entry), we've had an "unspoken" design choice, now they all do.
action_index() is called when there isn't a ?sa= specified, or even if there is: a default point of entry, from where the controller will forward to the right method. Just like our olde index.php is the point of entry in the whole app, action_index is (supposed to be) the point of entry in the controller class for the requests it handles. It allows to centralize things like permissions checks (common, usually), for admin controllers for example it was already done this way.

Additional note: most of changes in this PR are with Profile, some moderation I think, and the split of Xml controller. The rest of files have received a base class and at most a first method. I can't be sure, but I don't expect significant issues with conflicts. Let me know if you need time or tweaks or else, though. There are a couple missing (I'll add them later, if you don't first).