Fixes an issue with ScrollView inside an Overlay. While down events were propagated to the view, move events were consumed by the overlay preventing scroll components from functioning correctly.

Added overlay with a ScrollView for testing purposes

This reverts commit db24ecd25d.

scrollview is not scrollable when using overlay in android

Played around with context api, tried to get the wrapped component to rerender after global context
was updated - this is what I came up with.

Note: this commit makes the playground app use a newer js core as the js core which shipped with RN on Android
is missing javascript Proxy.

Closes #4517

Document options for Peek and Pop previews

required to run RN apps on Android 9 devices

Visibility events for both left and right SideMenu screens were not dispatched due to how the native
DrawerLayout is implemented.
Fixes #4303

Apparently TopBar elevation property is animated. Meaning that if 4dp elevation is set, when the
view appears its elevation is animated from 0dp to 4dp.
This resulted in rare race condition where the onAnimationEnd callback was called after
we set the desired elevation value, and an unexpected elevation value was set.

When set, the ui will become visible only after the root screen and TopBar components have been rendered.

Usage
Add the following to the root layout’s options, or to its child
```
animations: {
  setRoot: {
    waitForRender: true
  }
}
```

TopBar components (Title, background, buttons) can be synced as well by adding `waitForRender: true`, for example:
```
component: {
  name: 'navigation.playground.CustomTopBar',
  alignment: 'center',
  waitForRender: true,
}
```

## 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.

* added a fontFamily to OptionsTopBarButton type
* added modalTransitionStyle to the Options interface

Add typed interface for customTransition

Closes #4521

Until now tabs were added to screen in reverse order, meaning the last tab was attached to hierarchy first and the first tab was attached last.
This caused the first tab, which usually should appear first, to be rendered last as the root view’s startReactApplication was called last.
This commit changes render order so that the first tab is rendered first. Some apps will probably see an improvement in time to interaction as a result.

Accessing this value directly can lead to bugs as users might return a different
value from isDebug function which they override in MainApplication.

- `registerCommandListener` documentation was wrong so that is fixed
- use `uniqueIdProvider` much as possible so we are not duplicating logic
- add `appRegistryService` which makes `componentRegistry` cleaner and also makes testing easier
- type return type of `NativeEventsReceiver.ts` correctly
- add types to `LayoutTreeParser`
- `ComponentRegistry.test.tsx` refactor so it tests only things that is should and not implementation of React Native functions
- fix type `center` prop to be required on `LayoutSideMenu`
- add missing layout props `topTabs` and `externalComponent`
- lots of minor cleaning

Document Navigation.events() unsubscribe

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