Stricter adherence to mMaxRunningUsers

mMaxRunningUsers is a soft limit and can be exceeded in various cases.
Some of those make sense, others less so. Here, we get rid of the less
logical cases.

Changes:
  * When starting a user in the background (without specifying that it
    is for a temporary time only), we now trigger
    stopExcessRunningUsers(). This is new; we used to only do it for
    user-switches, not for background-user-starts. Background starts
    were seldom, but now that we actually use them (e.g. for alarms),
    we want to tighten this. (b/419867128)
  * We now allow user 0's profiles to be stopped during
    stopExcessRunningUsers(). This is new; we used to exempt them, even
    though we didn't exempt other user's profiles.
    (b/310249114#comment8)
  * If user 0's profile has DISALLOW_RUN_IN_BACKGROUND, we now do stop
    it when its parent enters the background, as one would expect.
    (b/324641317#comment3)
  * startProfiles(), which is called when switching to a user, will now
    ignore mMaxRunningUsers, and start all of the user's applicable
    profiles, even if that explicitly exceeds maxRunningUsers.
    (b/419872912) Reasons:
      * The previous code only allowed up to mMaxRunningUsers-1 profiles
        to be *automatically* started, presumably making the assumption
        that no other background users would be kept around (since
        historically, only user 0 could have profiles and there were no
        alwaysVisible users). Those assumptions are no longer valid,
        so it was already possible to exceed mMaxRunningUsers as a
        result. And anyway, one could always explicitly start additional
        profiles beyond mMaxRunningUsers.
      * This is probably a better user experience anyway (in the
        somewhat theoretical case where there are so many running
        profiles). If an OEM allows a user to have lots of profiles, it
        should accept the fact that they can run simultaneously.
      * I strongly suspect that the old code would have been very
        problematic if it actually triggered in real life, since the
        profile's quiet mode wouldn't have been respected and the UI
        probably would have broken as a result. Now we don't have to
        worry about it.
  * We also make sure to always stop excess users after starting the
    profiles. Previously certain code paths did call
    stopExcessRunningUsers() after startProfiles(), but others didn't.
    Now it is embedded in startUser, so it will always be called.
    (b/419872912)

Non-changes (ways mMaxRunningUsers can continue to be exceeded):
  * The current user and its related profiles are never stopped when
    switching/starting users, even if it has more profiles than
    mMaxRunningUsers.
  * If a background user is deemed important (e.g. because it is visible
    or audible), we may abstain from or defer stopping it, even if that
    causes us to exceed mMaxRunningUsers.
  * If we start a background user, and that triggers exceeding the max,
    we make sure we don't stop that same background user, even if it is
    the only available user to stop.

Bug: 419867128
Bug: 310249114
Bug: 324641317
Bug: 419872912
Test: UserControllerTest
Flag: android.multiuser.stop_excess_for_background_starts
Change-Id: I6dd420cf21492b7cab606bd476aa13de1a44406c