Audit: input fields have appropriate type & autocomplete attributes

There are three related things we want to audit:

1. **Input fields use appropriate `type`/`inputmode` attributes so they get custom keyboards on mobile**
1. **Payment forms marked up with `autocomplete` attributes so they get payment autofill magic.**
1. **Login forms marked up with `autocomplete` attributes so they get autofill/autocomplete magic**

In all three cases, ideal UX is Lighthouse analyzes each field and validates the appropriate `type` and `autocomplete` value is set on it.

----------

## appropriate input `inputmode` attributes

We want the user to get a nice keyboard on mobile when it makes sense. https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

(`input[type]` used to be the hack for this but is a bad choice now that inputmode is everywhere. :)

impl notes: `chrome://flags/#show-autofill-type-predictions` may help some. It provides this sort of data:


## `autocomplete` for payment forms

See:
* [Create Amazing Forms Recommended input name and autocomplete attribute values](https://developers.google.com/web/fundamentals/design-and-ui/input/forms/?hl=en#recommended_input_name_and_autocomplete_attribute_values)
* [Help users checkout faster with Autofill  |  Web  |  Google Developers](https://developers.google.com/web/updates/2015/06/checkout-faster-with-autofill?hl=en)
* [Autofill: What web devs should know, but don’t - Cloud Four](https://cloudfour.com/thinks/autofill-what-web-devs-should-know-but-dont/)

We'd like to consider the various input fields and suggest which autocomplete attribute value you should use for them. Basically one of the [53 autofill detail tokens](https://html.spec.whatwg.org/multipage/forms.html#autofill-detail-tokens) or `off` (if you dont want any autofill to apply (generally discouraged)) or `on` (if theres no appropriate token but you'd like autofill to attempt anyway)

`chrome://flags/#show-autofill-type-predictions` exposes what the current clientside and serverside heuristics are determining. We would take a lower confidence level than what Chrome would use to prompt the user, but the confidence rating isn't exposed currently.

## `autocomplete` for login forms

See:
* [Create Amazing Forms  |  Recommended input name and autocomplete attribute values](https://developers.google.com/web/fundamentals/design-and-ui/input/forms/?hl=en#recommended_input_name_and_autocomplete_attribute_values)
* [ensuring_continuity_between_your_app_and_web_site -- apple WWDC](http://devstreaming.apple.com/videos/wwdc/2014/506xxeo80e5kykp/506/506_ensuring_continuity_between_your_app_and_web_site.pdf) (page 177 and on)
* [Password Form Styles that Chromium Understands - The Chromium Projects](https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands)
* [Autofill: What web devs should know, but don’t - Cloud Four](https://cloudfour.com/thinks/autofill-what-web-devs-should-know-but-dont/)

input fields should get `autocomplete` attribute values of `username`, `current-password` `new-password`. This may or may not enable "Smart Lock for Passwords", new password generation, proper password saving, etc. We need to verify these as the documentation is sparse.

------

To enable this we'll need an `input-elements.js` gatherer:

Get all input elements, maybe grouped by ``. For each `input`, we'd want to know `type`, `name`, `autocomplete`, outerHTML snippet (like in a11y gatherer).