[TIMOB-26075] Android: Refactor app resume and "newintent" handling

*Summary:* Titanium's app resume handling from notification, shortcuts, intent-filters, etc. is problematic. It does not always resume and instead displays a new splash-screen instance which never runs the "app.js" (appears to hang) or a dialog stating that the app needs to be restarted (which can get stuck in an infinite loop). The following is a list of issues that have been reported. Some are flagged closed, but they're not completely resolved: * [TIMOB-1559] * [TIMOB-4941] * [TIMOB-9285] * [TIMOB-15253] * [TIMOB-24427] * [TIMOB-24747] * [TIMOB-25776] *Recommended Solution:* Get rid of *+all+* of the activity "restarting" code. No one likes this behavior. * [TiRootActivity.onCreate()](https://github.com/appcelerator/titanium_mobile/blob/master/android/titanium/src/java/org/appcelerator/titanium/TiRootActivity.java#L75) * [TiLaunchActivity.onCreate()](https://github.com/appcelerator/titanium_mobile/blob/master/android/titanium/src/java/org/appcelerator/titanium/TiLaunchActivity.java#L142) * [TiBaseActivity.onCreate()](https://github.com/appcelerator/titanium_mobile/blob/master/android/titanium/src/java/org/appcelerator/titanium/TiBaseActivity.java#L578) Drop support for Android bug 2373/5277 related "tiapp.xml" properties: * [link](https://docs.appcelerator.com/platform/latest/#!/guide/tiapp.xml_and_timodule.xml_Reference-section-src-29004921_tiapp.xmlandtimodule.xmlReference-PropertiestoworkaroundAndroidbugs2373and5277) In the main activity's onCreate(), we should do the following:

Check if TiApplication.getRootActivity() is not null. This tells us if a pre-existing activity window is already in the background and needs to be resumed. If it doesn't exist, then go ahead and create the activity (we're done).

Fetch the pre-existing root activity's intent. If we call Context.startActivity() with this intent, then it'll resume it with all of its child activity windows intact. _(This is what we're missing.)_

Call finish() for the new activity since we don't want to spawn a new instance. Attempt to disable the activity window's animation if possible via Activity.overridePendingTransition().

Have the pre-existing root activity fire a "newintent" event with the intent received by the new activity that we just finished/closed. (We must wait for the old activity task to resume first though.)

*Issues to Investigate:* * The Activity.getIntent() can return null in rare cases ([link](https://stackoverflow.com/questions/37856407/can-activity-getintent-ever-return-null)). We need to figure out how to resume the app's activity in this case. * We need to double check the necessity of TiBaseActivity.isUnsupportedReLaunch(). I suspect it's handling the case where a new Java runtime and Application instance is being re-created for a pre-existing app process (the C/C++ side's static variables still remember previous application info). * Check how this works with launchMode "singleTop". (It is being used by some community users. Although with this change, we shouldn't need it anymore.) * Re-test with Titanium's "Live-View" feature and Ti.App._restart() method to make sure they don't break. *Limitations:* * Titanium only supports running one V8 JavaScript runtime at a time. So, multiple activity tasks cannot be supported due to this limitation. This is partly why we need to refactor the app resume behavior. _(This may be fine from a portability standpoint anyways since iOS does not support this.)_ * We should avoid launchMode "singleTask" support. While it does what we want and makes an Android app work more like iOS, it comes with a huge limitation. A "singleTask" activity's child activity windows are all torn down by the Android OS after homing-out of the app and then resuming it. "singleTask" is only a viable solution if we re-architected Titanium to only support one activity and and all Ti.UI.Window objects spawned fragments instead, but this would be a major MAJOR breaking-change that is best avoided for now.