fix TabGroup fragment memory leaks, fix maps in tabs including when acti...

This fixes and improves the initial commit using the ViewPager for the TabGroup.
Issues solved:
1. Huge memory leak when the tab group activity was destroyed and later recreated (i.e. as in https://jira.appcelerator.org/browse/TIMOB-17016). The issue was that ever since 3.3.0 we have been keeping references to the fragments in our own data structures, and also never detaching and destroying fragment. So if this cycle happens a few times - memory explodes. This was masked by the crash we had until now.... The main fix was to remove ALL fragment references in our code.
2. The tab group needed to restore data structures coming back (same situation as in 17016), so that we can point to the correct fragments when coming back, and not blindly create new ones (the leak). So for this we had no choice but update TiLifecycle, and add onSaveInstanceState and onRestoreInstanceState. onSaveInstanceState is now used in the tab group.
3. We needed the restore state as early as possible (i.e. activity creation), so I had to add the restored Bundle to the windowCreated() calls. The tab group must use this, and it's a good thing - hopefully other window modules and can make use of this stuff and be more intelligent in their handling.
4. These are the key fixes. The rest of the changes are to accommodate  these infrastructure changes.

In general, this is very well tested, since it built on the testing done for the previous commit which was already heavy. Specifically tested: removing and adding tabs, using a map in the tabs, disabling and enabling tabs, doing all the previous then opening a new window (destroying the tab group activity), and then coming back to the tab group - all works splendidly and no memory leak.
Please merge ASAP since this fixes serious issues in the previous commit. Thanks!
We have changes like this in several files to enable activities to save and restore arbitrary data structures. This was absolutely required for the tab group, which needs to store/retrieve the IDs of the fragments in the FragmentManager in order to prevent leaks.