[Win32, Keyboard] TextInputPlugin is no longer a KeyboardHandlerBase

[dkwingsmt]

This PR refactors the Win32 keyboard system so that TextInputPlugin no longer derives from KeyboardHandlerBase. In this way, KeyboardKeyHandler is now the only KeyboardKeyBase.

With this change, the KeyboardHandlerBase abstract is practically useless, but is kept to minimize changes of this PR. In the future it will be simplified and absorbed into KeyboardKeyHandler.

This change serves two purposes:

Simply class structure

The previous structure, which consists of a two-layer abstract structure of KeyboardHandlerBase and KeyboardKeyHandlerDelegate, turns out to be over-engineering:

• The functionality of TextInputPlugin hardly overlaps with KeyboardKeyHandler at all. Making them derive the same base class adds a number of empty methods for KeyboardKeyHandler.
• Their only method in common is KeyboardHook, but TextInputPlugin.KeyboardHook never returns any value other than false. It's just a "listener".
• This structure won't even work if we are to add a 3rd KeyboardHandlerBase (fortunately, we don't.)

Simplify async flow

With this change, FlutterWindowsView::SendKey will contain only one potentially asynchronous subroutine.

As one of the most important steps of flutter/flutter#88021, it's planned to lift the redispatching mechanism from KeyboardKeyHandler to KeyboardManagerWin32, which needs to make FlutterWindowsView::SendKey an asynchronous function by adding a "callback" argument.

Currently FlutterWindowsView::SendKey traverses all of its 2 KeyboardHandlerBase to see if they'd like to handle the key. In theory, either KeyboardHandlerBase can return true synchronously, and decide not to handle the key later, causing a redispatch. Therefore, to make FlutterWindowsView::SendKey asynchronous, it will have to manually implement something similar to Promise.all. However, in practice, KeyboardKeyHandler is the only one that can be asynchronous, and by no longer recognizing TextInputPlugin as a KeyboardHandlerBase, the "callback" can be processed in a much simpler way.

---

This is one of the many steps to refactor the windows keyboard system.

This PR shouldn't need extra tests since it's only a refactor.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on
  writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[gspencergoog]

Modulo the make_unique changes.

[gspencergoog]

Why not keep the make_unique here? That way if someone later adds code that throws an exception or returns before the end of the function, this won't leak.

[gspencergoog]

Same here: use make_unique instead.