Immutable state on SSR (toString)

[tornqvist]

This PR solves state leaking between calls to toString and race conditions that occur during double render pass (bankai et al.).

The issue is that each call to toString would extend app.state, adding on more and more data for each render. If one was to expose the resulting app.state as window.initalState one would get the combined state from all prior calls to toString.
It is especially troublesome during double render pass (calling toString twice, once to allow events to trigger data being fetched and another to render the view with fetched data). If two attempts at a double render pass are issued in quick succession (e.g. server responding to several requests), both calls will mutate app.state and the first to finish will get the intermediate state of both render calls.

This PR ensures that the state passed into toString is only modified during that one pass through and that app.state remains untouched.

This would also allow us to proceed with choojs/bankai#446

Edit: Yet another issue solved by this PR is that every call to toString would initialize all stores and hence, add all listeners to the event bus over and over again for every render. This means that after a couple of renders any event listeners that e.g. fetches data will be fetching the same data several times over on every call to toString.

[bcomnes]

LGTM. Any weird edge cases or anomalies this could cause for people upgrading that we need to mention in a breaking change log?

[tornqvist]

The only real world effect it would have is for people and frameworks doing SSR and then plucking out e.g. title from the state. (I have prepared a PR to bankai for this: choojs/bankai#527)

var html = app.toString('/', state)
- var title = app.state.title
+ var title = state.title

The only other thing I can think of is that stores will now only have their event listeners triggered once per event (as opposed to accumulating listeners for each toString) and app.state will not be populated during toString. I'll make a point of mentioning this in the change log.