Tell IMS about missing InputConnection methods.

Summary:
  This CL introduces a unified mechanism to deal with the situation
  where the application directly implements InputConnection but some of
  methods are not implemented.  Note that there should be zero overhead
  when the application extends BaseInputConnection or
  InputConnectionWrapper.

Background:
  When ever we add a new method to InputConnection, there has been a
  risk that existing applications that directly implement
  InputConnection can get java.lang.AbstractMethodError exception at
  runtime, because older SDKs do not require the application developer
  to implement the methods that are newly added in later SDKs.  Because
  of this we strongly discouraged developers to directly implement
  InputConnection interface, and encouraged them to subclass
  BaseInputConnection or InputConnectionWrapper instead.  That said, as
  requested in Bug 26945674, there is a certain demand to be able to
  implement InputConnection without depending on BaseInputConnection.
  The goal of this CL is to provide a reliable and sustainable solution
  to above missing method scenario in InputConnection.

  One of the reasons why dealing with missing InputConnection methods is
  so difficult is that what InputMethodService receives to communicate
  with the target application is actually a proxy class
    com.android.internal.view.InputConnectionWrapper
  that runs in the IME process and immediately returns true for most of
  methods in InputConnection such as #commitText() and
  #finishComposingText().  Because of this asynchronous nature, it is
  too late to change the actual return value that the IME receives when
  the application receives those one-way asynchronous IPC calls.

Solution:
  To handle those cases, this CL checks the availability of
  InputConnection methods that did not exist in the initial release
  before the target application calls startInput(), and let the
  application to send its availability bits to IMMS so that
  InputConnectionWrapper running in the IME process can be initialized
  with such availability bits.  Note that we do know that
  BaseInputConnection and its subclasses support all the InputConnection
  methods, hence for most of applications we can just assume that all
  the methods are available without reflection.

  With such availability bits, InputConnectionWrapper is now able to
  gracefully return failure code to the IME because the availability of
  those methods is immutable, except for a tricky case where the
  application relies on a proxy object that dynamically changes the
  dispatch target.

  Here is the list of APIs that we start checking the availability in
  this CL.
    [API Level 9+]
     - InputConnection#getSelectedText(int)
     - InputConnection#setComposingRegion(int, int)
    [API Level 11+]
     - InputConnection#commitCorrection(CorrectionInfo)
    [API Level 21+]
     - InputConnection#requestCursorUpdates(int)}
    [API Level 24+]
     - InputConnection#deleteSurroundingTextInCodePoints(int, int)
     - InputConnection#getHandler()

Ideas alternatively considered: Default methods in InputConnection
  We once considered having default methods in InputConnection but
  abandoned this idea because it does not directly solve the problem
  about how to tell the that the API does not take effect.
  Also having default methods would make it difficult for application
  developers to be aware of newly added methods in InputConnection.

Bug: 27407234
Bug: 27642734
Bug: 27650039
Change-Id: I3c58fadd924fad72cb984f0c23d3099fd0295c64