Improve consistency in focusAfterDescendants behavior

- focusAfterDescendant ViewGroups that were also clusters would
  continue to be remembered for restoreFocusedInCluster after
  gaining focusable children. This caused undesired cluster-focus
  loops
- focusableViewAvailable wasn't being called in all cases (specifically
  when views were added). This meant focusAfterDescendant views
  wouldn't transfer focus to children in some cases.
- 0-area views which became focusable weren't reporting
  focusableViewAvailable. Since views gaining area doesn't report
  focusableViewAvailable, this was another case of state change not
  being accounted for. Also, this restriction doesn't exist for
  gaining focus so these views are actually focusable despite having
  0 area.
- focusableViewAvailable was reporting focusable views even when
  ancestors (and therefore the new focusables) were not visible.
- restoreFocusNotInCluster tried to focus invisible views
- restoreFocusNotInCluster was sending focus to focusAfterDescendant
  viewgroups which had focusable children IN a cluster.

Bug: 38010274
Bug: 38009598
Bug: 38352147
Test: cycling works in situations reported in bugs.
      Added CTS tests around focusableViewAvailable and
      FOCUS_AFTER_DESCENDANTS

Change-Id: I77f214f5384dcf9092324e08fc1daa3f1155bbad