Fix device restarts for private profiles with separate challenge

We have a bug for private profiles with separate challenge enabled
wherein the apps become unresponsive after the device restarts. This is
because the profile user is stuck in RUNNING_LOCKED state with the
storage still encrypted, as we haven't yet entered the LSKF
corresponding to the profile. This is already solved for managed
profiles with a separate challenge through the method
ActivityStartInterceptor.interceptWithConfirmCredentialsIfNeeded() and a
special case handling inside ActivityStarter.resolveStartActivity(). The
method inside ActivityStartInterceptor is written in a generic manner
and already allows all profiles that have a separate challenge enabled
to show the confirm credentials screen when the activity is started.
However, the ActivityStarter.resolveStartActivity has managed profile
specific checks that prevent the logic to be re-used by private profiles
causing the bug.

Please note that additionally the resolveStartActivity method is also
used to resolve activity for the scenario when the profile is in quiet
mode. This applies to both profiles with unified/separate challenge
mode. This is further used to launch the popup to unlock/unpause the
profile through
ActivityStarterInterceptor.interceptQuietProfileIfNeeded().

This CL adds the change to extend this check to all profiles, instead
of just the managed profiles to fix this issue. The logic is extended
to all profiles since the quiet mode feature (powered through
UserManagerService.requestQuietMode()/isQuietModeEnabled()) is available
for all profiles today.

Test: Tested by locally flashing the changes on a device with private
space with separate challenge enabled and restarting the devic to check
for the issue.
Bug: 304934183

Change-Id: I86e4193ced3dbdaec369a67c26a0cd2d08921c90