Description of problem - how things are handled in ReactNative's TextInput

There's a class in ReactNative's TextInput component, TextInputState (https://github.com/facebook/react-native/blob/95174d4ea8d050305885f3cc2a4c99e2b83fc961/Libraries/Components/TextInput/TextInputState.js) which holds information about focus for all TextInput components in the app (screen)

Unfortunately, InputTextState only knows about InputText and does not know about Aztec. As focus can only be held by one component at a time, we would (ideally) actually need to make TextInputState aware that Aztec is also something to take care of, so focus can be handled correctly (or build our own state-keeping for Aztec)

This cannot be done directly, as TextInputState only cares for RN's AndroidTextInput component in Android (iOS should apparently “just work” as it only keeps the node ID for it, without making a distinction of which class it is - we should verify nevertheless). For example, see focusTextInput() and blurTextInput() there in that class. This (only in part) explains why focus handling on iOS with the Aztec wrapper doesn't seem to be a problem.

Description of plan

The best way to go is to have something else that cares for both types of component (InputText and AztecText).

We also need Aztec to provide React Native with all methods for it to control its focus (work for this partially started in wordpress-mobile/react-native-aztec#75, replicating the API from RN InputText)

So current plan is: have a similarly built AztecState, and internally cascades back to TextInputState by usingTextInputState.currentlyFocusedField() and if there’s no “native” TextInput focused atm, looks into AztecState’s own state (otherwise, continue to run with the TextInputState implementation).

This way, ReactNative can keep working with focus for TextInput, and we would manage our own focus for AztecText components (and leave it up to the platform when we don’t have any focused items to take care of).

Keyboard show/hide works the same way: we should have a Keyboard.dismiss() of our own that does this check first, and be careful to always call our own method in our business logic (otherwise AztecText instances would not receive the signal to hide the keyboard). See related PR in #241, we should adapt these calls to use the new Gutenberg-focus manager that handles both state machines.

ToDo:

• build InputTextState for Aztec
• register components as they are added to the UI
• build mechanism to first check focus on InputText, then fallback to Aztec
• add needed methods in Aztec wrapper (RCTAztecView) to keep the same API
• implement keyboard hide/show sync for all (cascade Aztec arrays first, and then run through InputTextState's implementation.