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!
This check was not necessary and in fact was crashing the app on occasion due to https://code.google.com/p/android/issues/detail?id=42601 . The crash would occur because `tabFragment.getChildFragmentManager()` would sometimes be called prior to tabFragment.onActivityCreated occurring (although `getSupportFragmentManager` works fine at that point). The reason the 3.5.0 master works is that it does not set the ID "tabcontent", so we never called `getChildFragmentManager`...  However testing shows that we don't need it, and the sample app works perfectly without it. If we ever want `getChildFragmentManager` to be used, then it can only be called after fragment.onActivityCreated (unless Google fixes their bug). Nevertheless, it's not needed at this point.