Refactor accesskey extraction to include more cases

[eemeli]

Fixes #2603

The logic for detecting an accesskey is fixed and expanded to cover more cases. Previously, either the label attribute or the message value needed to have non-empty contents for the detection to succeed. Now:

• The input is rendered with accesskey styling independently of the number of candidate keys, but buttons next to it are rendered only if there at least two candidates.
• If a message has no label and no value, the value and aria-label attributes are also inspected.
• All non-letter and non-number candidates are dropped, though they may still be manually entered.
• Prefixed access keys are detected. If e.g. a message has attributes buttonlabel and buttonaccesskey, the former is used to generate the candidates for the latter.

[mathjazz]

The input is rendered with accesskey styling independently of the number of candidate keys, but buttons next to it are rendered only if there at least two candidates.

Not sure if that happens a lot, but why not show the button even for the single candidate? It would make the candidate, even if it's the only one, even more obvious. And I feel it'd be less surprising.

[eemeli]

Not sure if that happens a lot, but why not show the button even for the single candidate? It would make the candidate, even if it's the only one, even more obvious. And I feel it'd be less surprising.

@mathjazz Good point; removed the limit.