Don't let the heads up close too quickly.

The public API of HeadsUpNotificaitonView was not well suited to the
new requirements, so it changed slightly.

Old API:
 - showNotification: show or update a notification
 - clear: close the window and forget the notification
 - release: send the notification to the shade and forget about it.
 - releaseAndClose: release and close the window
 - dismiss: clear the notification if clearable, or release it

New API:
 - showNotification: show a new notification
 - updateNotification: show a new version of the same notification
 - removeNotification: respond to a cancel
 - release: send the notification to the shade at some point
 - releaseImmediately: send the notification to the shade right now

The new API makes updating vs. posting and removing vs. releasing more explicit.

There is a new internal concept: lingering.  The heads up lingers
after an event that would have closed it if the minimum visibility
time has not been satisfied. In the case that the notification was
deleted, the heads up may be visible, but mHeadsUp will be null.  In
this case, touches on the notification views are disabled.

More responsibility for control of the heads of policy was moved into
the HeadsUpNotificaitonView class. This should continue on master.

Some changes to support testing.

Added a test to cover all the edge cases for minimum visibility time:
 1. extend visibility when canceled too soon
 2. extend when updated with a low-priority version, fast update.
 3. extend when updated with a low-priority version, slow update.
 4. don't extend the visibility in any other case

TODO: Policy parts of HeadsUpNotificationView should be split out
into a separate HeadsUpNotificationPolicy class, and even more of the
policy should be lifted from status bar that new class.

Bug: 17878008
Change-Id: I192419d0685dd022ee7edcd792e346a4f39c6adb