Move `setupProfileTabs()` to the pager adapter

This splits out aspects of the "setup" behavior that are generic to
the pager adapter (building the tabs, setting up the event handlers)
from "application-specific" parameterizations (like providing the
strings for the tab labels, or implementing the event handlers in a
way that integrates with other UI elements in our app).

These changes are as prototyped in ag/25335069 and described in
go/chooser-ntab-refactoring, in particular replicating the changes of
"snapshot 31" and "snapshot 32." See below for a "by-snapshot"
breakdown of the incremental changes composed in this CL.

Snapshot 1: separate the `setupProfileTabs()` design within
`ResolverActivity` so it's easier to see the diffs before moving to
the pager adapter. A newly-introduced static method (of the same name)
takes over most of the implementation, while parameterizing the
details we'll consider "application-specific." Notably, this splits
up two existing "callback" designs that had both "generic" and
"application-specific" responsibilities -- our `OnTabChangedListener`
and `MultiProfilePagerAdapter.OnProfileSelectedListener` (which,
TODO: might be consolidated to a single design in the future?).
The "generic" aspects of these listeners move to the newly-extracted
static method, but the listeners also compose-in application-specific
behavior that's provided in the parameterization.

Snapshot 2: move the parameterized method into the pager-adapter
(replace "static" and use the pager-adapter "implicit this" instead
of taking it as the explicit first parameter).

Snapshot 3: integrate ChooserActivity with the "parameterized method"
that was extracted to the pager adapter. This wasn't part of the
original prototype but is needed now that ChooserActivity no longer
inherits a shared implementation from ResolverActivity. Equivalence
is clear from side-by-side reading of the pager-adapter implementation
and the (before-change) ChooserActivity implementation.

Snapshot 4: move `updateActiveTabStyle()` from a caller "parameter"
of `setupProfileTabs()` to an internal implementation detail in the
pager-adapter, and generalize the behavior to support any number of
tabs. (This was "snapshot 32" in the original prototype.)

Bug: 310211468
Test: `IntentResolver-tests-actvity`, `ResolverActivityTest`
Change-Id: Ifc3a0d81d148241966041f7efd74774f22a933d7