The login workflow needs to be updated to support a possible Captcha. (This would actually make it more consistent with the Create Account workflow, which already supports a captcha.)
The logic for whether to show a captcha is a bit roundabout (different from the logic when creating an account), and looks roughly like this:
* Make the initial call to `action=clientlogin` as we do currently.
* If the response is `PASS`, then we're good to go, and logged in (no change from current behavior).
* If the response is `FAIL`, regardless of the actual error provided, we need to //make another call// to [[ https://en.wikipedia.org/w/api.php?action=query&format=json&meta=authmanagerinfo&formatversion=2&amirequestsfor=login&amimergerequestfields=1 | authmanagerinfo ]] and examine its response.
* If the authmanagerinfo response contains a `requests` object with an id of `CaptchaAuthenticationRequest`, that's our indication that we need to provide a captcha. One of the `fields` in the response will be a `captchaId`, which we can use in the same way as we do in the Create Account workflow, and send the `captchaWord` parameter in our next call to clientlogin (i.e. restart at step 1).
* If the authmanagerinfo response does //not// contain a `CaptchaAuthenticationRequest`, then we can treat the original clientlogin response as the true error, and show it to the user.