Replace bottom keys in emoji / clipboard view with keyboard

[Helium314]

WIP PR for having an actual keyboard at the bottom row of emoji and clipboard views.
This enables key swipes and allows easily customizing this layout.

At the moment the implementation is very basic, and only done for emoji view.
To do:

• do not crash when getting popups in main keyboard
• use the "normal" full width spacebar by default
• improve switching back to normal keyboard (currently switches on key press with unexpected consequences, but should rather be on key release) fixed by using alpha key instead of symbol_alpha
• use more in-place mechanisms for building the keyboard
• move code out of emoji view, so it can be used for clipboard too
• make it customizable (maybe not in this PR)

fixes #850
fixes #593
fixes #404

[devycarol]

Does the AOSP keyboard have a special view for the emoji layout, or was that added in OpenBoard with the smooth-scrolling?

You once mentioned a challenge of perhaps implementing d-pad arrow keys that span multiple rows. I wonder if these special layouts could be entirely composed of special MainKeyboardView objects. A small emoji window as a bonus top-row similar to the number row would be kinda wack.

[Helium314]

Does the AOSP keyboard have a special view for the emoji layout, or was that added in OpenBoard with the smooth-scrolling?

I only have LineageOS variant of AOSP keyboard ready, but looking at the existence of emoji layout files I'd say it's in AOSP.
LineageOS emoji keyboards scroll left/right instead of up/down, but look pretty similar otherwise.

You once mentioned a challenge of perhaps implementing d-pad arrow keys that span multiple rows

Essentially the issue with multi-row keys is not that it's really difficult, but the keyboard parser and builder are both based on rows. Hardcoding a specific layout should be relateively simple, but there is some additional work involved in making this configurable (plus the customization would need yet another format).

I wonder if these special layouts could be entirely composed of special MainKeyboardView objects

You mean every key is a separate keyboard?

A small emoji window as a bonus top-row similar to the number row would be kinda wack.

Hmm, using one row of the already wanted two-row suggestion strip / toolbar might be more suitable.

[Helium314]

The PointerTracker crash issue is somewhat tricky.
It happens because the PointerTracker instances share some static objects that are coming from the MainKeyboardView, created in init. This does not work any more if we have multiple MainKeyboardViews.
The ancient comment above init TODO: Add PointerTrackerFactory singleton and move some class static methods into it. would be a way to fix the problem. Though maybe I'll try making it work in a simpler way... (edit: done, revert c5c5d88 when doing it properly)