Use RESPONSE_CRED_INCORRECT for Weaver INCORRECT_KEY with nonzero timeout

Translate Weaver statuses of INCORRECT_KEY with nonzero timeout into
RESPONSE_CRED_INCORRECT instead of RESPONSE_RETRY.  The timeout remains
the same and is still available in the VerifyCredentialResponse.

The result is that in this case
LockSettingsService#reportResultToSoftwareRateLimiter() will tell the
software rate-limiter the guess is certainly wrong.  This allows
duplicates of it to be detected, whereas previously they weren't
detected.  Note that given the current software rate-limiting schedule
combined with the 5 minute expiration time on the saved wrong guesses,
this makes a difference only for (unique) guess number 5.  I.e., when
making guess 6, duplicates of guess 5 are now detected.

Previously, VerifyCredentialResponse#hasTimeout() checked whether the
response code was RESPONSE_RETRY.  Make it instead check for nonzero
timeout, so that it also returns true for RESPONSE_CRED_INCORRECT
responses with nonzero timeout (which previously used RESPONSE_RETRY).

Technically, this does change the behavior of hasTimeout() in the edge
case where GateKeeper returns RETRY with zero timeout or Weaver returns
THROTTLE with zero timeout.  But that is not supposed to happen, and
even if it does, the new behavior seems correct anyway.  The purpose of
checking for RESPONSE_RETRY was to determine whether there is a timeout.
If the timeout is zero, then there is no timeout.

Bug: 423038471
Test: atest FrameworksServicesTests:com.android.server.locksettings
Test: manually tested detection of duplication with guess #5 as
      described above, on a device whose Weaver implementation uses
      INCORRECT_KEY with nonzero timeout so is affected by this change.
Flag: android.security.software_ratelimiter
Change-Id: I414481de5c314a1ac2f274f1910563396721271c