This new updateProps command allows to update props for a component registered with Navigation.registerComponent.
The updated props are handled by shouldComponentUpdate and componentDidUpdate lifecycle methods.
This commit builds upon the work done in 291f16177d and is a breaking change.

This commit adds support to update props of screen or custom button/title via the mergeOptions api.

```js
Navigation.mergeOptions('myComponentId', {
  passProps: {
    text: 'new value'
  }
});
```

Using lodash.set caused issues when keys contained the dot symbol. _.set created objects inside the store, which is intended to be a simple key value dictionary -
In some cases, set would overwrite previously set values.

## What this PR is about?
Finally all strict rules are enables for TypeScript compiler! 🎉 Basically previously `noImplicitAny` was turned off but now it plus all strict rules are turned ON! 💋 

## Some highlights of the changes
- `Element` renamed internally to `SharedElement` to make more sense what is it
- `LayoutTreeParser`'s responsibility is now to do all `id` related stuff. Previously it was spread between `LayoutTreeCrawler` and `LayoutTreeParse` so it is more simple now
- clean up a lot of tests because they were testing duplicate stuff that was covered by other tests already
- removed all usages of `static get options` and replaces them with `static options`. This is how it is in the docs plus you cannot have `static get options(passProps)` because it is impossible to have getter with parameters.

Remove some implicit anys and refactor tests

* Remove tests that test that lodash cloneDeep works

Fix name collision so autocomplete works

Refactor component name to be number also

* Avoid calling component generators on registerComponent

* fix unit tests

* remove console.log

* fix coverage

* fix coverage

[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