AttachedSurfaceControl: Add setTouchableRegion API

Add an API for setting touchable regions. This API allows
a view hierarchy to allow touches to pass through its
surface in certain regions. Touch pass through of course
follows the regular rules about UID/PID origins and
touchable region does not effect the calculation of the
TOUCH_OBSCURED flag. Such an API has existed as @hide
since the beginning of time, via
ViewTreeObserver.ComputeInternalInsetsListener. The API has already been
wrapped in the IME system, and in VoiceInteractionSession.
Desire to make the API public is motivated by 3 use cases:
	1. GameOverlayService UI code moving out of framework
	required for their UX (multiple small buttons in a large
	transparent overlay)
	2. SurfaceControlViewHost: A common point request among
	people who ask me about SurfaceControlViewHost is to be able
	to embed the SurfaceControlViewHost in a SurfaceView which is
	"setZOrderOnTop(false)" (hole punching) so that the host
	hierarchy can draw on top of the embedded hierarchy in some
	regions. This is possible today, but there will be no way
	to receive input without input hole punching.
	3. There may be cases where apps are using multiple Popup type
	windows which could be combined in to one. In general reducing
	HWC layer count this way will be a good trade off.

It was considered to ViewTreeObserver.ComputeInternalInsetsListener
directly but ultimately decided against it for a few reasons:
	1. Obscure naming
	2. Other fields not useful for our use cases.
	   Because insets/touchable region linkage not a useful API concept for
	   us
	3. Forces dispatch model via callbacks which may or may not be
           useful for a given app.

It was also considered to create a gatherTouchableRegion API mirroring
gatherTransparentRegion. Such a concept (as setting root surface
touchable regions) is not really composable though. For example
maybe a parent view requires touch regions, then a child view
one day starts removing them. The fact that input order is not
simply reverse drawing order (since parents come before children
in both) means there is no way to ensure this always cleanly composes
as expected. Given this, it's better to expose a "global" API
and require the app developer to understand how their components
are fitting together, rather than invite a View implementer
to subclass gatherTouchableRegion and allow someone to break them.

Bug: 213603716
Bug: 214239892
Test: SetTouchableRegionTest, SurfaceControlViewHostTests
Change-Id: Ie49caec964455b7129daa2aaa6990a368309f8e9