Input: Fix some Applications ANR issue in monkey test

Issue Description:
When do monkey test on some applications, there is big probability get ANR issue. one example is as following:
    adb shell monkey -p com.google.android.street -v 500000

Root Cause:
situation 1. InputDispatcher Thread calls findTouchedWindowTargetsLocked routine, there is a AMOTION_EVENT_ACTION_DOWN event
             and it can find a splittable touched window for this event , then mTouchState.split set to true.

situation 2. WMS Thread calls setInputWindows routine and all TouchedWindows associated with mTouchState are removed ,
             mTouchState.split status still keep true.

situation 3. InputDispatcher Thread calls findTouchedWindowTargetsLocked routine, there is a AMOTION_EVENT_ACTION_POINTER_DOWN event
             and it can find found touched window, exit window loop in following code :
                  if (windowInfo->visible) {
                    if (! (flags & InputWindowInfo::FLAG_NOT_TOUCHABLE)) {
                        isTouchModal = (flags & (InputWindowInfo::FLAG_NOT_FOCUSABLE
                                | InputWindowInfo::FLAG_NOT_TOUCH_MODAL)) == 0;
                        if (isTouchModal || windowInfo->touchableRegionContainsPoint(x, y)) {
                            if (! screenWasOff
                                    || (flags & InputWindowInfo::FLAG_TOUCHABLE_WHEN_WAKING)) {
                                newTouchedWindowHandle = windowHandle;
                            }
                            break; // found touched window, exit window loop
                        }
                    }

situation 4. The following code will have problem after situation 3 in below conditions:
             newTouchedWindowHandle doesn't support split , isSplit is true ( last time touched window is splittable )
             mTempTouchState.getFirstForegroundWindowHandle will always return NULL due to situation 2

            // Figure out whether splitting will be allowed for this window.
            if (newTouchedWindowHandle != NULL
                    && newTouchedWindowHandle->getInfo()->supportsSplitTouch()) {
                // New window supports splitting.
                isSplit = true;
            } else if (isSplit) {
                // New window does not support splitting but we have already split events.
                // Assign the pointer to the first foreground window we find.
                // (May be NULL which is why we put this code block before the next check.)
                newTouchedWindowHandle = mTempTouchState.getFirstForegroundWindowHandle();
            }

            The window says it does not want to support splitting, so the touches should go to one of the previously split windows except
            that there are none, which result to "goto Unresponsive" in findtouchedWindowTargetsLocked routine.
            This is not the correct behavior because the user did actually touch something.

situation 5. InputDispatcher Thread will call dispatchOnce repeated to try to dispatch this AMOTION_EVENT_ACTION_POINTER_DOWN event,
             then ANR timeout ( 5000ms ) will be exceeded after several times "goto Unresponsive"in findtouchedWindowTargetsLocked routine.

Solution:
In situation 4 we should drop the touch. If the newly touched window was splittable then we wouldn't drop the touch.
It's only when the newly touched window was not splittable where we will drop the touch.

Change-Id: Iab2c06ce0597ac77eb886ccd9d84646c86723bdb
Author: Jeffrey Brown <jeffbrown@android.com>
Author: Erjun Ding <erjunx.ding@intel.com>
Author: Zhenghua Wang <zhenghua.wang@intel.com>
Author: Jack Ren <jack.ren@intel.com>
Author: Bruce Beare <bruce.j.beare@intel.com>