Refactor right buttons

This pr started with an attempt to eliminate button flickering entirely when updating buttons which contain react components via mergeOptions. While the attempt wasn't 100% successful, I dit get some insights in the process.

* It's not possible to add buttons at specific indices. Buttons contain an order property which determines the order of the button in the TopBar. To somewhat overcome this limitation, we can let users control button order via options.

* When a right most component button is replaced with another component button, the rest of the buttons shift to the right since the newly added component isn't measured when it's added to the menu and its width is zero. 
We usually handle this situation with the `waitForRender` option but since buttons are measured with `MeasureSpec.UNSPECIFIED`, their dimensions are zero. Because of this, I've added options to set button dimensions.

* When updating buttons via mergeOptions, if a component button is already added to the menu with the same order we will not remove and added it again. This mitigates flickering in some situations.

* Textual button style properties were applied by traversing the view hierarchy and searching for the TextView corresponding to the button and updating its styles directly.
There was an inherent bug in this logic where if two buttons contained the same text, styles could have been applied to the wrong TextView. We now apply styles directly on the button using spans.

* Cleanup and reorganise playground app

* Separated tests into three categories
  1. Layouts - layout specific tests and feature showcase
  2. Options - options related tests; interactions between static and dynamic options, merge options etc
  3. Navigation - general navigation features; Orientation handling, events, Overlay etc

* Fixed a few Android bugs
  1. testID wasn’t applied on TopBar react buttons
  2. static options were disregarded when creating initial BottomTab options
  3. Trying to open a none existent SideMenu would result in a crash

* Fix e2e tests

* Fix lint

* Few fixes + split push from SideMenu test into two tests

* Fixes e2e

This change lets buttons stretch horizontally using padding and
margins and not only by changing width property explicitly.

[BREAKING] Call Navigation.events().bindComponent(this) to listen to lifecycle events

This commit introduces breaking changes to the way components listen to RNN events.


Background

Up until now, components could handle navigation events by implemented a set of callbacks:
* componentDidAppear
* componentDidDisappear
* onNavigationButtonPressed
* onSearchBarUpdated
* onSearchBarCancelPressed

While this worked fine for the most part, this was completely broken for HOCs as RNN invoked these methods only on the registered component (top most HOC), leaving it to the user to propagate these events down the HOC chain. See the discussion in #1642 for more details.


Solution

In order to support HOC use case, we're introducing a new api which will let any Component bind itself to receive navigation events:

```js
class LifecycleScreen extends Component {
  constructor(props) {
    super(props);
    this.subscription = Navigation.events().bindComponent(this);
  }

  componentWillUnmount() {
    // The subscription is removed automatically when components unmount, but they can be explicitly removed as well by calling `this.subscription.remove(); `
  }
}
```

It's still the users responsibility to propagate the `componentId` down the HOC chain, but by binding a component to RNN, it will be able to handle events as expected. Multiple components can be bound for the same `componentId`.


Consolidate event names

* onNavigationButtonPressed -> navigationButtonPressed
* onSearchBarUpdated -> searchBarUpdated
* onSearchBarCancelPressed -> searchBarCancelPressed

* TopBar custom buttons initial commit

* f

* Consolidate TopBarButtonController and TopBarButton

* Move Toolbar related stuff to TitleBar

* TitleBarTest

* More tests