Defer resetLockout and execute on a separate thread

Renamed hasChallenge to be @IntDef ChallengeType so we can properly
track the origin of the challenge throughout the various method calls.

For each unlock, generateChallenge is now invoked only once, even if
multiple profiles for that user exist. This is the only hwbinder/HIDL
invocation in the critical path of unlock. The resetLockout and
revokeChallenge invocations are now executed on a separate thread after
all profiles are unlocked.

Bug: 133738703
Test: With work profile and one lock enabled, generateChallenge() is
      seen only once. resetLockout() is seen twice, and revokeChallenge()
      is seen once.

Change-Id: I6ef369aeac92d1b89d23359d03ffaccd5176b104