RFC: Making *Locations full-fledged Action Creators

[gaearon]

As discussed in #252, I would like to be able to differentiate between user- and browser-initiated events.
This allows us to avoid trying to restore scroll position when user clicks on links.

@mjackson and I thought that perhaps turning *Location objects into full-fledged action creators helps achieve that goal.
Current path state would move into PathStore which becomes less sophisticated.

In this pull request, I'd like to ask @mjackson and @rpflorence to comment on whether we proceed with this approach, seeing how I changed HistoryLocation and PathStore. (Scrolling is not implemented here, but this PR is pre-requisite for implementing proper scrolling anyway.)

This approach is more in line with Flux:

• All actions (whether user's or browser's) go through the same flow
• PathStore only keeps track of store instead of doing stuff

The downsides (?):

• Custom Locations now need to know about LocationDispatcher, ActionTypes and PayloadSources
• The action-creating parts of HistoryLocation will be duplicated in all Locations, they get more fat

I don't think these problems are that bad, but I'd like a few opinions before going ahead with this.
Thanks!

[gaearon]

Actually I just realized I might not need to complicate *Locations at all. Instead of onChange, they might accept onPop which is triggered only when browser pop occurs. All dispatcher calls can be placed inside LocationActions this way.

[gaearon]

For the sake of keeping Locations simple, I moved firing actions back to LocationActions for now.
If we really need something more than onPop, we can do this later.

[gaearon]

Closing this for now, since there's a simple way.