1/n: Allow LockSettingsService to return Gatekeeper Password

For certain scenarios, it's ideal if a single prompt for the user's
credential could generate multiple Gatekeeper HATs, each containing
a distinct challenge. To do so, we expose the gatekeeper password
to the caller, which can then be sent to LockSettingsService to
mint a Gatekeeper HAT with a challenge specified by the caller.

Functionally, this is split into two pieces:
1) ILockSettings#verifyCredential* has a new flags parameter,
   which if contains VERIFY_FLAG_RETURN_GK_PW, returns the gatekeeper
   password
2) ILockSettings introduces a new method, verifyGatekeeperPassword,
   which takes the Gatekeeper Password and challenge, from which
   Gatekeeper creates a HardwareAuthToken. This is different than
   the rest of spBasedDoverifyCredential and __only__ requests
   Gatekeeper to create the HardwareAuthToken. It does not proceed
   to do other things such as unlocking keystore keys, unlocking
   managed profiles, etc.

Slightly cleaned up VerifyCredentialResponse: moved to builder pattern,
cleaned up serialization/deserialization

Returning a VerifyCredentialResponse object (instead of a byte[])
also makes it easier to debug failure cases (e.g. credential was
verified but HAT was null, vs originally we have no idea). Similarly,
this allows us to remove RequestThrottledException, which can help
make it easier to reason about code flow (less unexpected nullness)

Test: Clients with VERIFY_FLAG_RETURN_GK_PW have correct "accept,
      reject, timeout" behavior
Test: Current biometric enrollment works and not affected
Test: PIN/Pattern/Password verifyGatekeeperPassword works
      (see ag/12222644)

Bug: 161765592
Change-Id: I6e2a7ea234aac1a278b35cdaff62b1c7e3e9f205