Use role/aria-role to identify input boxes

Describe the bug

When an input box is a custom implementation (like for some code editors), it appears that at least under some circumstances vimium will not correctly recgnize the input box as a input box and will not switch into input mode when the input box receives focus.

To Reproduce

Steps to reproduce the behavior:
I've noticed this on the Posthog website

1. Create an account and project on the posthog website (https://us.posthog.com/)
2. Open feature flags, create new feature flag, multivariate feature flag (probably reproduces on the non-multivariate too, but that is where I noticed it)
3. Focus the payload input box. Tap j or k to type the letter, notice the page scrolling instead.

Including the DOM for the element having focus, too:

<div class="native-edit-context" autocorrect="off" autocapitalize="off" autocomplete="off" spellcheck="false" tabindex="0" role="textbox" aria-required="false" aria-multiline="true" aria-autocomplete="both" aria-roledescription="editor" aria-role="input" aria-label="Editor content" style="tab-size: 30.7969px; text-wrap: nowrap; font-family: Consolas, &quot;Courier New&quot;, monospace; font-weight: normal; font-size: 14px; font-feature-settings: &quot;liga&quot; 0, &quot;calt&quot; 0; font-variation-settings: normal; line-height: 19px; letter-spacing: 0px; top: 8px; left: 7px; height: 19px;"></div>

Browser and Vimium version

Google Chrome 142.0.7444.176 (Official Build) (64-bit) (cohort: Stable)
Vimium 2.3.1

Reproduce the issue on the PostHog feature-flag payload editor using the supplied DOM and confirm that focus does not enter input mode. Locate Vimium's input-element detection, then check how role="textbox" and aria-role="input" are handled. Done means the custom editor is recognized and j/k are inserted instead of scrolling, with regression coverage if the existing tests support it.