Keep GUIControls alive after window deinit

This is resurrection of #127 in much more complete state:

Window's controls are being deleted on window deinit. This results in loading xml, resolving includes, parsing resolved xml and creating controls everytime user activate window.

This will allow to keep controls objects in memory on window deinit. It also will store xml windows root node that could be used if load type is set to load_on_demand (old style - few windows are still like this) or if include condition have changed value.

Some numbers (tested on raspberry pi with slow sd card where it will have biggest impact I guess): compare alloc resources time for first and second window inits. (I didn't really gather data, just ran xbmc 3 times and given that results were similliar I called it done)

```
===== Results (numbers from Raspberry Pi) ====

  1. Home Window

     -- First window init will be same as usual --

	00:02:33 T:1096794832   DEBUG: ------ Window Init (Home.xml) ------
	00:02:33 T:1096794832    INFO: Loading skin file: Home.xml, load type: on demand and keep in memory after window deinit
	00:02:33 T:1096794832   DEBUG: Load Home.xml: 665.98ms
	00:02:34 T:1096794832   DEBUG: Alloc resources: 723.72ms  (666.55 ms skin load)

     -- Second window init --

	00:03:24 T:1096794832   DEBUG: ------ Window Init (Home.xml) ------
	00:03:24 T:1096794832   DEBUG: Window Home.xml was already loaded
	00:03:24 T:1096794832   DEBUG: Alloc resources: 22.07m

  2. Video Nav

	00:03:18 T:1096794832   DEBUG: ------ Window Init (MyVideoNav.xml) ------
	00:03:18 T:1096794832    INFO: Loading skin file: MyVideoNav.xml, load type: on demand and keep in memory after window deinit
	00:03:19 T:1096794832   DEBUG: Load MyVideoNav.xml: 776.83ms
	00:03:19 T:1096794832   DEBUG: Alloc resources: 827.03ms  (777.33 ms skin load)

	00:03:30 T:1096794832   DEBUG: ------ Window Init (MyVideoNav.xml) ------
	00:03:30 T:1096794832   DEBUG: Window MyVideoNav.xml was already loaded
	00:03:30 T:1096794832   DEBUG: Alloc resources: 27.48m
```

On android (skin.retouched) Home.xml was loaded 1st time: 126ms and 2nd time: 5ms (that's total alloc resources time). On my desktop with ssd - home.xml = 1st time: 42ms, 2nd time: 4ms. So it's not that spectacular everywhere. Note: alloc resources times don't include time spent in OnWindowInit (f.e. video nav window fetch directory there)!

Here's list of windows that weren't yet adjusted/tested if they will work "as-is":
```
Still on to-do list but not really high priority:
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: screencalibration (file: SettingsScreenCalibration.xml, ID: 10011)
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: filestackingdialog (file: DialogFileStacking.xml, ID: 12008)

Didn't have any karaoke samples so at least for now I leave them as they are with old style xml loading every init. Do they still work at all?
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: karaokeselector (file: DialogKaraokeSongSelector.xml, ID: 10143)
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: karaokelargeselector (file: DialogKaraokeSongSelectorLarge.xml, ID: 10144)
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: karaoke (file: MusicKaraokeLyrics.xml, ID: 12009)

For no-xml windows load type doesn't matter so they can stay as they are.
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: teletext (file: no xml file, ID: 10600)
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: unkown window (file: no xml file, ID: 97) <= Dim Screensaver Window
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: unkown window (file: no xml file, ID: 98) <= Debug Overlay Window
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: screensaver (file: no xml file, ID: 12900)

CGUIDialogSubMenu class used only as base for "submenu" type custom windows (which wasn't used by any of few skins I have: confluence, aeon-nox, xeebo). No DialogSubMenu.xml in confluence. Nuke that window?
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: submenu (file: DialogSubMenu.xml, ID: 10105)

Used only after playing with GUISetting that aren't shown in GUI. No DialogAccessPoints.xml in confluence. Nuke that window?
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: accesspoints (file: DialogAccessPoints.xml, ID: 10141)

Loaded and shown once - no sense in keeping it in memory.
00:02:30 T:1096794832   DEBUG: GUIWindowManager: LOAD_ON_DEMAND window: startup (file: Startup.xml, ID: 12999)
```

And finally - my branch currently contains 2(3) last temporary commits (they will be removed later) to
1. help me notice what windows weren't adjusted yet (it generated window list above)
2. enable/disable feature on runtime (in gui settings) to check what impact it have
(3). add window loadtype to log on window load (depends on how verbose we want to be)