Summary: If `options.async` is enabled, it's possible for `activity` to
be called a second time before the first call's paired `finishUpdate` is
triggered. Then, when the second call to `finishUpdate` happens, the
still-active widget in `completion.widget` is unceremoneously
overwritten and can now never be closed. This leads to a lot of weird
and broken behavior, notably an autocomplete window in the browser that
never goes away and can insert its text over and over and over.

Test Plan: This is really hard to trigger. My project consists of a
webworker providing autocomplete, which has some latency before it calls
the `finishUpdate` callback. But it depends on the exact latency and
even the user's typing speed to whether things happen in just the right
order. I basically just added and deleted characters with the
autocomplete prompt open a bunch until it eventually reproduced. After
applying this patch, several minutes of bashing didn't trigger the issue
again.

Issue #2390

Closes #2381

Issue #1474 was the cause of this hack
Issue #2384 was apparently caused by it

Recent Webkit-ish browsers seem to no longer have the problem that
it was working around.

And style them differently from unknown properties.

Issue #2356

Issue #2373

Closes #2374

Closes #2376

Add tests. Adjust addons that depended on previous token structure.

Also improve indentation around implicit end tags in HTML.

Issue #2176
Issue #2333

[vim] Implement ": and ". registers

Issue #2352

[vim] Unit test coverage for 't' and 'f' search commands within macros, and fix handling of '/'

Issue #2334

Use CreateInsertModeChanges to make a copy of the latest
insert mode changes in pushInsertModeChanges so that the
latest insert mode changes can safely be modified without
bashing previously recorded macros.

Fix the :register command and add unit tests. Add a fakeOpenNotification for matching the notification text.

Issue #2326

Issue #2326

It causes noticeable missinge scrollbar in some cases.

Closes #2317