Consider consolidating all link hints commands to one: LinkHints.activate

Today we have several very similar link hints commands. Each one specifies an option to a core command.

To improve this and allow people to combine these orthogonal options together, we could move to one command, LinkHints.activate, which takes parameters to customize its behavior:

• action: open, focus, hover, copy
• destination/placement: current tab, new tab, new window
• multiple: i.e. open many at once; currently LinkHints.activateModeWithQueue
• focus on open: whether to switch immediately to the new tab
• incognito: whether the destination should be an incognito window

This would make it seamless to add in long-tail use cases for the link hints command, like opening a link in a new window rather than a new tab (#3450).

These are the historical reasons we have separate commands for each parameter:

1. We added each link hints variant one at a time over many years.
2. The ability to have user-specified options on Vimium commands was added much later.
3. The only way we expose documentation about commands is in the help dialog, which even today doesn't have a way of listing and explaining the various options that some commands accept. However, we're progressing the UX towards this capability. Now the help dialog shows if a user has added any options to commands they've bound; next is to implement a better UX for documenting all commands and their allowed options (see #2827 for inspiration).

Backwards compatibility: we can either migrate people's existing configurations at the time they are read, or we can indefinitely support e.g. LinkHints.activateModeToOpenInNewTab as an alias for LinkHints.activate destination=newTab.

Related: #1948.

Start by reviewing the existing LinkHints commands and the LinkHints.activate entry point, then inspect how command options are documented in the help dialog and how configurations are read. Done means the link-hints variants are consolidated around the proposed options, existing configurations remain compatible, and the related use cases in #3450 and #1948 are addressed.