Pull ChooserTargetInfo API up to base TargetInfo.
As in ag/20189669, this makes the concrete type into an implementation
detail while allowing clients to operate in terms of the more general
base interface (with an eye, long-term, towards potentially
"flattening" this class hierarchy, per go/chooser-targetinfo-cleanup).
After this CL, clients that only "access" but don't "create" target
objects shouldn't need to know the concrete type of any instance on
ChooserTargetInfo side of the tree (i.e., clients only potentially
need to care about the runtime type of targets that descend from
DisplayResolveInfo -- until that side too can be cleaned up in a
future CL).
Test: atest IntentResolverUnitTests
Bug: 202167050
Change-Id: I47d54c64971e1c0ca2a4953d347eb4323a598f5c
8 files changed
