propose cleaner, more familiar usage patterns

[aarongreenwald]

This PR modifies the example app to encourage/propose a usage pattern that is more familiar to React Native developers, feels less invasive, and better highlights some of the power of this solution by showing how it can be used to create a clean separation of concerns between multiple modules in the same application.

• The app is initialized with a navigator that knows what tabs/drawers to create, and imports modules that provide a single function that registers their screens. These modules might even be npm modules, developed in different repositories and by entirely separate teams. The modules' only responsibility to the navigator is that they namespace their screen names to ensure uniqueness and that they export a function that registers all their pushable screens.
• A screen's implementation should look like a regular React Native Component. A developer working on a project using react-native-navigation should feel at home immediately and adoption shouldn't feel like a lot of change. The README doesn't seem very scary, but looking at the example made me kind of wrinkle my nose a bit. :)
  • It's unnecessary to import everything that is being pushed all the time. (It's also not possible, because some of the pushed screens are in different modules. You know the screen's name and that's it.)
  • You still need to extend Screen instead of Component. I'm considering ways around this, but I'm not sure it's a good idea so we'll come back to this. If we come up with a way to use this solution declaratively we'll probably be able to get rid of the Screen business along with all uses of this.navigator.
• It wasn't immediately obvious to me that you only need to extend Screen if you want to reference the navigator inside the screen. You can push any component if it's registered, regardless of type. I'm not sure how often people have screens that don't do any navigation, but I suppose it could happen. I think clarifying this reduces the amount of mysterious magic going on.

I might be missing something in the implementation that makes my proposal back recommendation. If this isn't feasible or if you think it's not a good idea, let me know.

[talkol]

Unrelated to this PR, I added full redux support. When doing so, I had to change the API slightly to handle redux connected components easily. I updated example according to the new API style, let me know if this change achieves the same purpose as your suggestion:

https://github.com/wix/react-native-navigation/blob/master/example
https://github.com/wix/react-native-navigation/blob/master/example-redux

[aarongreenwald]

@talkol I like what you did in the two examples, I think they are both much better and achieve the same results plus more, so I'm closing this. Thanks!