Reconsider how `List String` is used to represent a location change

[rgrempel]

As noted in the README, I've been conceiving of a location change fundamentally in terms of a List String that is normalized/de-normalized via uriEncode / uriDecode and joining and splitting on slashes.

This is meant to be a convenience -- for instance, in a modular app each level can simply dispatch and then add things to the List (in delta2update), and consume what it wants from the List and dispatch the rest (in location2action).

However, in writing up some examples, I've realized that this is a little tricky if you're dispatching to multiple children and they might return lists of variable length. When you're back in location2action, how do you know where one child ends and the next begins?

Now, there are a variety of schemes that the app can invent for that. But, it might be nice to come up with some pleasant 'sugar' for the usual cases. This may or may not mean moving away from List String as the fundamental representation of the change.

In part, this turns on what the URL should actually look like for cases of multiple children etc.

[rgrempel]

Having thought about this a little more, I think it would be better to have the main API work with String rather than List String. That will give people the most possible flexibility in encoding and decoding URLs. I can still supply the normalizing and denormalizing that I now do, but as separate functions that you need to opt into.

Part of my reasoning is that when doing the Elm Architecture Tutorial examples, I realized that there are a number of potential schemes you might want to adopt for the URL, depending on how your data is structured, and how you want the URL to appear. While List String is a convenience in some cases, in others it doesn't really help. So, I should allow for potentially multiple schemes for managing that -- what I have now would just be one.

For people who like what I have now, it shouldn't be more than inserting one function call to get current behaviour. And, perhaps I can set it up so that it can be partially applied, so you can get a function that does what happens now.

[rgrempel]

@jasonzoladz pointed out the very interesting elm-combine module:

http://package.elm-lang.org/packages/Bogdanp/elm-combine/latest https://github.com/Bogdanp/elm-combine

It looks like something which would be very valuable for parsing the URL -- should explore building a URL-oriented layer on top of it.

[rgrempel]

For elm-route-hash 2.0, I'm fundamentally just asking for a String as the URL -- producing the string will be a separate concern, since it can be done in a variety of ways. And, I'm providing the whole Location object, so the client can pick out whatever is interesting from it ...