Batch shortcut results to a single Handler message.

The one-at-a-time processing model was vestigial from supporting
ChooserTargetService. If we need to process n shortcuts, it's
inefficient to context-switch and handle n+1 messages (including
the completion message) if we can instead pack all n results into a
single message. The new approach is also much simpler, since we
now know we have all the data on hand before proceeding - previously
we forced an "unbatched" processing model on the downstream clients,
and then had to design around the problems that *that* created
(in particular, I haven't confirmed yet, but I *suspect* that we
could get rid of the 250ms LIST_VIEW_UPDATE_MESSAGE delay after this
change, since now we can just send that message a single time at
the end of the batch without worrying about throttling). Further
cleanup like that will come in a later CL -- for now this is the
minimum change required to adopt a batch-processing model.

I claim that this change is safe because there was no benefit to
the one-at-a-time streaming model -- it didn't cause results to
appear to the user any faster. We already had the full set of
results on hand when we started emitting these messages from
ChooserActivity::sendShareShortcutInfoList; the per-result
processing we do in that loop isn't very expensive (and it runs in
the same thread as the ChooserHandler anyways); and even if we were
somehow picking up a marginal benefit, it would've been masked by
the 250ms timeout.

(There *maybe* could be some concern if ChooserListAdapter's
addServiceResults is too expensive for us to block and call for each
result in the batch, but 1. that seems unlikely; 2. if there *is*
anything expensive about addServiceResults we can probably optimize
it by switching to a batch-processing model in the Adapter as well;
and 3. if the Adapter needs to subdivide these tasks to remain
performant, it should take that responsibility on for itself.)

This optimization was made possible by the removal of
ChooserTargetService support (since in the old model, we actually
*didn't* have all the results on hand at the start).

Test: manual & atest
Change-Id: Iaaab546cc274bf1879941901260b7ade62cbcaa5