Persist map settings / add map settings to URLs

[ezwelty]

We will eventually need to support the many legacy url parameters (see #246) that control map settings:

https://fallingfruit.org/?z=11&y=47.41426&x=8.55928&m=true&t=roadmap&l=false&c=forager,freegan

• x, y, z – Map longitude, latitude, and zom: Either map to @{y},{x},{z}z (as used now) or rename @{y},{x},{z}z to x={x}&y={y}&z={z}
• m (default: 'true') – Municipal tree inventories: Set settings checkbox state and map to GET api/locations?muni=.
• f – Location types (comma-separated type ids): Set type filter state and map to GET api/locations?types=.
• c (default: 'forager,freegan') – Location type categories (forager, freegan, grafter, honeybee): Map to type filter based on type.categories returned by GET api/types.
• t (default: 'roadmap') – Map type ('roadmap': Google default, 'hybrid': Google satellite, 'terrain': Google terrain, 'toner-lite': Stamen toner-lite, named here 'osm-toner-lite' but could be renamed back to 'toner-lite', 'osm': OpenStreetMap standard, named here 'osm-standard' but could be renamed back to 'osm'). Legacy URLs do not support overlays (bicycle and transit).
• l (lowercase L) (default: 'false') – Location labels: Set label checkbox state

At the same time, there are good reasons to persist map settings so that they survive map refresh (#516). Even better, that they persist between visits on the same device, as the language selector appears to do already.

So to recap:

• Load settings from legacy url parameters
• Write settings to local storage (cookie?) alongside language
• Write settings to URL (ideally, matching and extending legacy params) without adding a new state to browser history

[wbazant]

No full plan for this yet, but I had some thoughts, there's a difference between params and settings:

• params specify the page
• settings customise the site

There are controls which we want to persist into Redux because we want them to be linkable - users can share them with one another, but maybe in the future if we had a type page it could link to a map with only that type checked, e.g. /map?types=1337. Meanwhile, there are also controls that are individual to the user: site language is the most obvious one, but maybe someone with accessibility needs or a specific device they use will prefer a particular map type or a label setting.

We should also support params from the old site but that can be a one way binding - and almost as a separate issue, there should be a local storage backup of settings.