Support legacy map URL parameters

[ezwelty]

We will eventually need to support the many legacy url parameters (see https://github.com/falling-fruit/falling-fruit-web/issues/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

Probably as a later followup issue:

There are good reasons to persist map settings so that they survive map refresh (https://github.com/falling-fruit/falling-fruit-web/issues/516). Even better, that they persist between visits on the same device, as the language selector appears to do already.

• [ ] 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.

[ezwelty]

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.

@wbazant Agreed. To keep us focused on the beta release, I've focused this issue on supporting params from the old site.