Support for changing share map hash

[steff-o]

Resolves #1453.

This PR makes it possible to update the hash part of the url to change to another sharemap state.

The map is completely "rebooted" to fully reflect the new incoming map state. In order to do so without messing around too much in the viewer a completely new Viewer is created instead of trying to restore all state. As a new viewer is created, external code that uses the 'load'-event should also reinitialise itself using the new viewer.

[jokd]

How about making initViewer take a new config as an argument so it can be used to load a new config as well? Or add a setConfig method to origo.js to do just that ( but then maybe you can't roll back to default config)

[steff-o]

It actually kind of already takes a new config as param. It is included in the sharemap hash and the usual config resolving is used. If no mapstate is present it resolves to the default or configured .json file. When a mapstate is present the map argument is used. It is not however possible to just call initViewer with another config. I did not want to mess around too much with the config resolving inside the Viewer.

Maybe a good combination of getting exactly what the sharemap state says and a possibility to only change the current state of the map would be checking if the map hash argument is present. If it is present a "reboot" using the provided config is performed. If it is not present, all other hash arguments are read and applied to the current state. E.g. it would be possible to only change the extent or select a feature or put a pin or turn on or off layers or a combination of those actions by setting the desired hash arguments.

But to be honest, I don't think I will implement setting individual arguments as I see no strong use case as it is possible to achieve that by using the api and it would require some serious rewriting of the Viewer if the code would not have to be duplicated. The main objective with this PR is to handle when an iframe is reused with different mapstate hashes.

What I will do is however add a check if the map argument actually has changed in order to avoid reloading the map if an application has its own hashchange handler dealing with other arguments. When that is in place there will be a suitable place to start implementing all other arguments that can be set in the hash if someone needs it.

[steff-o]

I changed the code to only reboot the map if the map parameter is specified in order to allow for application to use its own hashes. All other parameters or hashes are ignored unless in combination with map parameter.

[steff-o]

@jokd Do you want me to change anything? I think I have implemented what I wanted and have no plans to do anything more on this unless there is something that needs to be changed.

[tonnyandersson]

@jokd, any final thoughts on this? If not, I'll approve and merge this by the end of the week, 'cuz LGTM.