Consolidate start new input scenerios

As CL[1] we introduced WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR start
input reason to ignore start new input when the focused view is
same as current served view and the input connection remains the same for
prevent additonal onStartInput / onFinishInput callback to
InputMethodService.

The main idea in the CL is good but how to judge whether the input connection
remains the same is not accurate.

CL[1] only checking if IMM#mServedInputConnectionWrapper self and its
input connection instance is stil exists, that breaks the following cases
to start new input:

Case 1:
- When device screen off / on to go back to focused app, this case will
  fit WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR use case, so
  IMM#mServedInputConnectionWrapper won't be deactivate and clear, this
  makes wrong when user taps IME picker dialog to switch IME, will hit
  again WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR and never start new
  input for new IME.
  Actually, in InputMethodManager has an ad-hoc check mRestartOnNextWindowFocus
  to start new input when device screen off / on case and switching IME,
  we should not ignore start input since that will conflict with the above
  case.

Case 2:
- As served view is now tracked by ImeFocusController which is per-window
  based instance from the IME focus handling refectoring CL[2],
  but InputMethodManager instance is still per-display based, so
  IMM#mCurrentTextBoxAttribute might be changed when the same app clinet has
  multiple IME focusable window focus changed, because focusing to the next
  IME focusable window will start new input connection and changes
  IMM#mCurrentTextBoxAttribute, so when focusing back to the
  original window, the served view in the original window's
  ImeFocusController will same as focused view, in that case if we didn't
  check if IMM#mCurrentTextBoxAttribute is really aligned with the given
  focused view, will mis-judge start new input timing and caused user can't
  type because the input connection state is obsoleted.

Those cases can be addessed by using new introduced method
IMM#isSameEditorAndAcceptingText, if the focused view is not aligned
with same editor or the editor is inactive, we should start new input
for Case 2, that also can fix Case 1 that we previously ignored starting
new input when switching IME.

Beside, we also found CL[3] leverages
InputMethodManager#mRestartOnNextWindowFocus to start new input when window focus
changed, since originally this ad-hoc check is only used to re-start input
for Case 1.
As we re-visited the necessary start new input scenerio is only when:
   - Device screen off -> on
   - Switching IME
   - the input connection obsoleted
     (this also includes when window focus changed)

As the result, we can remove all unnecessary logics in IMMS
instroduced by CL[1] and remove unnecessary
InputMethodManager#mRestartOnNextWindowFocus from CL[3], and preserve
the behavior is almost same as Q.

[1]: I2da99ae67b9ce4051dec0c0f0e975ebe6e1ab118
[2]: Ib455704fe1e9d243f93190a84f230210dbceac2a
[3]: I8d4fff94ba9313b773bc27fcbd019cc88580d3e9

Fix: 160391516
Bug: 158624922
Bug: 152373385

Test: atest FocusHandlingTest
Test: atest InputMethodServiceLifecycleTest
Test: manual for case 1
     0) pre-install 3rd party IME app
     1) launch message app and taps Search bar to focus.
     2) turn off screen
     3) turn on screen to back to focused app
     4) press IME switch icon from nav bar
     5) choose next IME, expect the IME should be changed.
Test: manual for case 2
    0) Sample app with 2 activites, each activity the layout has
       EditText
    1) Launch activity A, focus EditText
    2) Launch activity B and focus EditText
    3) Press back key to back to activity A
    4) Verify if typing with keyboard is workable.

Change-Id: I1ef3d341af9d473d94d52fd1890deafbae2bc9e1