Handle BadTokenException exception more reliably.

This is a follow up for I2c21573cf972145ab08e66604cdb9344139a3f31, which
added BadTokenException handler so that we can deal with unavoidable
runtime exceptions. However, it turns out that CL does not work well
in a certain case.

One problem in I2c21573cf972145ab08e66604cdb9344139a3f31 that it added
the exception handler in the call site of
InputMethodService#showWindow(boolean) rather than callee side as
follows.

    try {
        showWindow(true);
    } catch (BadTokenException e) {
        if (DEBUG) Log.v(TAG, "BadTokenException: IME is done.");
        mWindowVisible = false;
    }

However, the above code fails to update #mWindowVisible if an IME
overrides InputMethodService#showWindow(boolean) but catch-and-ignore
BadTokenException as follows.

    @Override
    public void showWindow(boolean showInput) {
        try {
            super.showWindow(showInput);
            // Do something if super.showWindow() succeeds.
        } catch (BadTokenException ex) {
            // Do something if super.showWindow() fails.
        }
    }

With this CL, InputMethodService#mWindowVisible is always updated in
the callee side whenever it should be.

Note that this CL does not change anything about which method can
throw BadTokenException and which method catch-and-ignores it so as
not to break existing IMEs unexpectedly.

Bug: 23798142
Change-Id: Id1e5f236f48c8ef01b7f157ba3f6e7ab2c26b135