* Refactor peek and pop

* Rollback some XCode stuff

* Added tests for touchablePreview event

* Also fixing searchbarcancelpressed event

* Making sure tests work

* Refactored modals

* Added unit tests for modals

* fixes unknown modal dismissing and added tests

This reverts commit 4c519acae8.

* Refactor peek and pop

* Rollback some XCode stuff

* Added tests for touchablePreview event

* Also fixing searchbarcancelpressed event

[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

Summary: This adds a new event `onSearchBarCancelPressed` that fires
when the user presses the cancel button on the search bar in the
navigation bar. `onSearchBarUpdated` does indirectly fire when the user
presses cancel, as the query will be reset to an empty string, but it is
not possible to distinguish those events from the user simply resetting
the query. My use case for this is to have a view that appears on top of
the normal content of the view controller when the search bar is
focused.

Test Plan: ran `npm run test-js` and confirmed added JS unit tests
passed.

I also tested this with my app, and confirmed the
`onSearchBarCancelPressed` method was called when I pressed the cancel
button.

* [ios11+] Add searchBar option for topBar

* Fix formatting and linter issues

* Add docs about topBar.searchBar

* Fix missing semicolons

* Revert prettier changes

* Add js tests for onSearchBarUpdated to achieve 100% coverage

* Mark searchBar test as :ios: specific

* adresses #1078

* Renamed onStop/onStart to didAppear/DidDisappear

* This did't make it!