feat(scrolling): switch to smooth scrolling by default + increase compat

[RobertCraigie]

TODOs:

• test this on linux
• what if you've overriden the default arrowkeys/pageup etc? can you?
• double check the shortcuts we use will always be defined
• breaking change notification for existing users with instant scrolling example
• retain way to opt-in to the old behaviour?
• docs for configuring scroll speed etc
• ahhhhhhhhh this breaks when using G/gg mappings in an editable context
  • hmm for G / gg I think this is worse, but for <c-d> it's more questionable
• doc on why this is the way it is (I think it's just generally better to model hjkl and co as arrow keys for better compat even outside of just scrolling)
• add <C-,> or similar to blur element
  • how to make the existence of this obvious?
• add tests that these keymappings are element scoped now
• notification for gg / G in particular
• notification for <C-d> / <C-u> in particular
• make sure excmd naming/index docs accurately reflect their behaviour now

---

We now treat:

• hjkl as just normal arrow keys
• <c-u>/<c-d> as <pageup>/<pagedown>
• G as <D-down>/<C-end> on macos/linux
• gg as <D-up>/<C-home> on macos/linux

This change was made for a couple reasons:

1. we get a great smooth scrolling implementation for free, as Firefox's default for arrow keys is smooth scrolling.
2. just sending arrow keys increases compatibility, the previous implementation was very buggy, and would straight up not work in some cases, e.g. PDFs, or just stop working randomly

This is not a free lunch change though, as we're now sending arrow keys to the content frame for hjkl, there are some implications, both good and bad.

It's good because a website could have custom behaviour for arrow keys that is more desirable than trying to scroll the frame

It's also bad for the same reason, a user could reasonably be surprised that hjkl no longer scrolls on a particular website they're using.

I think the trade off here is worth it for the increased compatibility and smooth scrolling. We can revisit this in the future if it is indeed problematic.

I also did try to figure out if it'd be possible to just call the internal Firefox functions that pressing arrow keys ends up calling, but that posed to be quite difficult. All of that logic is entrenched heavily with the expectation that there is a KeyboardEvent. Additionally attempting to just call the deeper internals, just resulted in the same bugs that the current implementation has.

I wouldn't be surprised if there is a better way to do this, but I
don't think it's worth more time investment here trying to figure that
out.

notes:

• It looks0 like you cannot override Firefox builtin shortcuts so they don't work anymore with just stock Firefox. You probably could break this behaviour through an extension.

closes #105