Restore app expectations around drawable visibility change timing

When we update drawable visibility has changed to be part of
View.onVisibilityChanged instead of an overload of
setVisibility. While this covers more cases that we were previously
missing, it also means that we now set drawable visibility from the
View constructor via the call chain view.setFlags to
view.onVisibilityChanged to drawable.setVisibility, resulting in us
passing a 'this' pointer all over before the object is fully
initialized. (i.e. a Bad Thing.)

In general we've gotten away with playing fast and loose with this
sort of thing as a part of view inflation - calling various non-final
setters that may invoke callbacks as needed rather than initializing
view fields directly. Unfortunately it also means that we can cause a
lot of hard to trace bugs and in the long run we should try to clean
up as much of it as we can.

In this case, some apps were expecting inflation to have finished
completely before any drawable visibility changed. If a view's
visibility changes but it's not attached to a window, does it make a
callback?

The fix: no. We won't dispatch onVisibilityChanged to detached views,
but we will dispatch it when a view becomes attached.

Also fix a bug where we could end up telling a view its visibility
changed to (INVISIBLE | GONE), which just doesn't make any sense.

Bug 20103422

Change-Id: Ifba54c36114e85cf64869afcca766c30d601a16c