What is this?
This PR continues the work on making this project type safe with TypeScript. Goal is that the flag noImplicitAny will be set to true

What this PR does?
* all files inside adapter folder is valid for noImplicitAny!
* resolveAssetSource is now imported from the current place where it should. Previously it was imported from legacy location. More info here: https://facebook.github.io/react-native/docs/image#resolveassetsource
* formatted many files
* add missing interfaces
* fix onPressIn prop on TouchablePreview

What's next?
Next I am planning to make same treatment for commands folder and many it valid for noImplicitAny 🎉

Added wagng/react-native-navigation-redux-starter-kit

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

This bug caused orientation set in defaultOptions to be disregarded.

Setting default orientation is still somewhat wrong now that its behaviour has changed when targeting SDK 28.

## Goal of this PR
The goal of this PR is to make `OptionsProcessor.ts` great again 🇺🇸 . To me it was total mess including tests. 

## What was wrong or funky?
1. the tests tested if React Native's `processColor` color works as it should even though react native has [multiple tests for this](https://github.com/facebook/react-native/blob/master/Libraries/StyleSheet/__tests__/processColor-test.js). Aka we don't have to test React Native's functions :D
2. `LayoutTreeCrawler.test.ts` was testing `OptionsProcessor`s functionality so it was removed now
3. Lots of small things since this was done before putting `noImplicitAny` to true so it wasn't made TypeScript in mind

## Result
Now `OptionsProcessor.ts` should be
1. code way more clear
2. tests are testing only things that they should
3. tests are written in clear way
4. it is easy to see from the tests what the whole function does
5. type safe for TypeScript `noImplicitAny` (when we actually turn it on)

When pushing a screen into a stack in the centre controller with `sideMenu.left/right.visible: false` - side menu was not closed as expected.
This happened because when either side menus is open, it’s considered the current child and when options are resolved. the centre controller’s options were ignored.

This commit fixes this issue on Android. When resolving options, the centre controllers options are resolved as well.
Related to #4267

Closes #3664

* Use correct path for WorkingLocally

* Plugin init is now deprecated

* docsify-copy-code stylesheet is deprecated

* Use HTTPS, set Docsify version to 4.7.1 and copy-code to version 2

Couple of Docsify Github issues point that there are some rendering problems with 4.8.3 so let's anchor Docsify at 4.7.1 for now

* Stop override tabBarItem by parent layouts

* Fix unit

Create BottomTabs once when options are applied

The BottomTabs library we use recreates its children each time a style property changes.
This can hinder performance quite a bit as the view creation logic is quite costly.
This commit introduces a simple fix to this issue - we delay view creation until all options are applied.

BottomTabs refactor
* Prevent view recreation in `onSizeChanged`
* Cleanup `createTabs` method

Only change is visibility modifier of createItems so it can now be overridden

This property is used to set background color only for components,
unlike backgroundColor which sets color for every type of layout.

Motivation
When a view appears, its options are resolved according to its
currently displayed children. Basically this means that child options
are hoisted to the parent as children can declare options which effect
their parent.
This means that if a component has declared layout.backgroundColor or
if that property was declared in defaultOptions, each view will have a
background color, which might contribute to a significant overdraw.

Coses #4466

This property can be used to control how the SideMenu is opened using swipe gesture

bezel - only swipes from the side of the screen open the side menu
entireScreen - Swipe from any area of the screen will open the SideMenu

This PR adds support for setting stack root with multiple children, which is to be expected as stack can be initialised with multiple children.
Closes #4441

Remove some implicit anys and refactor tests

* Remove tests that test that lodash cloneDeep works

The following PR introduces improved support for Context api and other api's which wrap the root view.

## Context api
Navigation.registerComponent('navigation.playground.ContextScreen', () => (props) => (
  <TitleContext.Provider value={'Title from Provider'}>
    <ContextScreen {...props} />
  </TitleContext.Provider>
), () => ContextScreen);

## Redux
Navigation.registerComponent('navigation.playground.ReduxScreen', () => (props) => (
  <Provider store={reduxStore}>
    <ReduxScreen {...props} />
  </Provider>
), () => ReduxScreen);

## Plain Component - not changed
Navigation.registerComponent('navigation.playground.MyScreen', () => MyScreen);

This PR also upgrades the TypeScript version to 3.2.0 and RN version used in the playground app to 0.57.7

* New Android build flavor - `reactNative57_7`
* Unit test coverage is disabled, for some reason it broke after upgrading to RN 0.57.7

Initialize and pass mainWindow to commandsHandler

Fix name collision so autocomplete works

* Fix typo in setStackRoot animation docs

* Use 'enabled' instead of 'enable'

Until now controlling drawers touch gestures was impossible, drawers received gesture opening touch from the entire screen and that causes collisions with other gestures (which are implemented on the javascript side).

This commit adding modes for how sideMenu drawers gestures will receive opening touch.
```
{
  sideMenu: {
    openGestureMode: 'entireScreen' | 'bezel'
  }
}
```

- `entireScreen`: drawer gesture will trigger drawer opening from the entire screen
- `bezel`: drawer gesture will trigger drawer opening only from the center screen bezel frame

The default didn't change.