re arch

[franleplant]

This is a rough draft of some of the things discussed in #10

Unordered comments:

• I tried using an explicit localHandle and remoteHandle but I ended up reverting to a simple shallower structure, I did incorporate the concepts though: emitToRemote and emitToLocal are the main replacements, the remoteHandle.addEventListener is replaced by Bridge.on and all the event methods that Emittery provides, we might be able to make these things a bit more explicit but I think it has a good balance between explicitness, simplicity and clarity.
• Bridge class. It is not the main host of all the wrapping that we do on top of onmessage and postMessage, it is an event emitter (Emittery) and it provides bidirectional remote method calling (it both can call a remote bridge methods via .get and also hosts methods that can be called by another remote bridge instance). There's no concept of Child or Parent at this point since both sides of the "Bridge" do exactly the same.
• Parent and Child add the handshake mechanisms on top of the primitives that Bridge provides (I love this structure).
• Bridge has a similar interface to Post-me Parent/Childhandshake (localWindow, remoteWindow, remoteOrigin, methods/models)

I left a bunch of TODOs or comments inline in the code, I didn't got all the way with refactors and still a lot left TODO, for example, for speed sake I kept get instead of call which I think it is a better concept to use.

@alesgenova feel free to do whatever with this PR

[franleplant]

since Bridge is a module that is going to be used from both "parent" and "child" perhaps we want to make it an instance variable with a variable prefix so that we get differentiated output when debugging

[franleplant]

I really like how simple this module got

[franleplant]

I'd like a more structured approach to event creation, i.e. this could probably be abstracted like this.emitToRemote(...events.getResponse({id, property, value, error}))