DO NOT MERGE Refactoring of fitSystemWindows to applyWindowInsets for views

Applying insets is now handled by:

* WindowInsets class - Encapsulate system insets and local decor
  insets into a single object, written specifically so that new inset
  categories may be added later. Apps cannot construct their own
  WindowInsets, only clone with optional modifications. This is to
  prevent losing data in the event of new insets added in the future.

* onApplyWindowInsets - Actually perform the application of insets.

* OnApplyWindowInsetsListener - Allow an app to use a separate
  Listener object to apply insets to a View. This allows for things
  like support lib integration in custom views written for older
  versions where the verifier would otherwise complain about the use
  of the new WindowInsets class as a method parameter. It also allows
  for applying insets in a custom way without writing a custom view.

* dispatchApplyWindowInsets - Dispatch the call to self and children
  in turn, if applicable. An OnApplyWindowInsetsListener will override
  the behavior of the view's default onApplyWindowInsets method; a
  listener wishing to call down to the 'superclass' implementation as
  part of its own operation should call view.onApplyWindowInsets. App
  code should generally not override this method and instead override
  onApplyWindowInsets or provide a listener.

Compatibility support with the existing fitSystemWindows method has
been provided in both directions: for code that previously called
fitSystemWindows on arbitrary views and also for code that overrode
the fitSystemWindows method in custom views. A view that supports the
newer onApplyWindowInsets mechanism should not mix that behavior with
other calls to fitSystemWindows or vice versa. Support lib-style code
should take care to consistently use one mechanism or the other at
runtime.

Change-Id: Ie88b96e0382beb5d3c3f6cd013f7043acbc0a105