Consolidate disabling fixed-rotation when IME may visible on activity

CL[1],[2] disables fixed-rotation when the IME may possible to shown on
the launching activity for fixing Bug the IME janking issue that seeing
both portrait and landscape IME surface.

The CLs use ImeSourceProvider#getSource().mVisibleFrame to predict if
the IME may visible during activity launching, which is not very
predictable to reflect the true IME client visiblity, like when user
intentially presses back key to hide keyboard but somehow mVisibleFrame
may not always be null. So that the issue will happen when launching
the activity from the caller with different orientation, even previously
the IME has been hidden, the fixed-rotation won't happen as expected.

The reason is the visible insets of visibleFrame
is reported from InputMethodService#onComputeInsets that
can be overrided by IME developer, so we can't expect the visibleFrame
should always null.

Another reason is TaskSnapshot#hasImeVisible is not correct because
setHasImeVisible uses isDrawn instead of isVisible to reflect the actual
IME visiblity when snapshoting the task.

To fix this issue, we should remove and fix those misleading checks as
the above, and add reliable visiblity checks to see if the IME window
is really possible to show on the launching activity.
(e.g. mHasSurface, mViewVisibility, softInputMode of the activity
window..)

[1]: Idfdf129adbfbee6634d8a27aa78da1f631bd213b
[2]: I966ab69f260f828b6e96b3479a36467181288504

Fix: 189014002
Bug: 160451808
Test: manual as below steps:
1) launching the app (e.g. Chrome) with focusing IME in portrait mode
2) swiping out to launcher
3) rotate the device in landscape
4) tapping the shortcut to launch the app again
5) see if the app will be launched with normal rotation animation
6) press back key to hide IME
7) swiping out to launcher
8) tapping the shortcut to launch the app again
9) see if the app will be launched with fixed-rotation.

Change-Id: Idef12249806e4a6860b8cd190df4f0f8cad13c19