Skip "last-chosen" query for Chooser

`getLastChosen()` is invoked in the course of the generic/"base-class"
`ResolverListAdapter::rebuildList()`, and the result is cached as
`mLastChosen`. By inspection, `mLastChosen` is *only* ever read by
`ResolverListAdapter` methods that are gated on `mFilterLastUsed`
(except when it's used internally to derive `mLastChosenPosition`, but
that field is *also* only used in conjunction with `mFilterLastUsed`).

`mFilterLastUsed` is final and false in all instances of the
`ChooserListAdapter` subclass (i.e., any `ChooserActivity`
configuration): go/chooser-mfilterlastused-false.

In some cases (for unknown reason, b/335196436), the call to
`getLastChosen()` crashes in Chooser; this CL should safely workaround
that problem. Even if it wasn't failing, we could expect some
performance boost by omitting the unnecessary system call.

Note that Chooser configurations will still call `setLastChosen()`
(via the base `ResolverActivity::onTargetSelected()`) to *write*
this setting in the system, so it'll still be reflected in subsequent
*ResolverActivity* sessions -- it's just never *read* in Chooser.
Writing from Chooser probably has only "marginal" user value, but
there's no need to change that legacy behavior at this time.

Test: existing `IntentForwarder` & CTS tests.
Bug: 335196436
Flag: EXEMPT bugfix
Change-Id: Ieaf4bc713d51494a6a3ada89810f232b8875108f