store vs. Store vs. AltStore confusion

The docs describe being able to set initial store state in a constructor, by assigning to `this.state`.

It seems reasonable to assume that doing it subsequently, in a store callback, should work too - but this isn't the case! Handlers are bound to Store, not AltStore, so setting `this.state` is just going to reassign it inside of Store, without affecting the reference in AltStore. You have to use setState.

On the other hand, if you don't set `this.state` in the constructor, then AltStore implicitly assumes you're setting properties directly on the store class. So if you later on assign to `this.state` from some function that's bound to Store (e.g, from an async action, or in the 'init' lifecycle handler), the AltStore will now contain your value in `store.state.state` rather than `store.state`.

Also, if you mutate, rather than reassign, it'll all appear to work (e.g, this.state.foo = 3), which is extra confusing.

Exported public methods are all copied (and thus default-bound) onto the AltStore.

Now throw ES6 fat arrow functions into the mix and you basically never know what `this` is...

So I think the easiest thing here would be to keep a single source of `state`, since much of the confusion comes from AltStore having its own `state` variable. I'm not sure what the implications are in the rest of the library if you do that, though.

Start by tracing how Store and AltStore bind handlers, copy exported public methods, and represent state across constructors, store callbacks, async actions, and the init lifecycle handler. Determine the implications of maintaining one state source, then add coverage for assignment and mutation through each mentioned entry point; done means the state behavior is consistent and documented.

Written by the indexing model from the issue text.