[Not finished, discussion] Making languages dynamic with command arguments

**Heya!** 

Thanks for this amazing library! Photon is best suited for our geocoding autocomplete needs compared to Nominatim (which we still use for reverse-geocoding and details). 

I made some changes to allow for dynamic languages in Photon. We specifically needed to add Dutch as a language, and while I went over the language-specific code in Photon, I noticed that it wouldn't be too hard to make it fully dynamic. 

The way it works now is as follows: 

### To specify languages that should be imported during nominatim-import
Use the `nominatim-import-languages` command argument. i.e.
`java -jar photon-0.1.2.jar -nominatim-import -nominatim-import-languages nl,en -host localhost -port 5432 -database nominatim -user user -password password` 
for importing only the default, en and nl tags.

This could also be handy to keep Photon data as small as possible without languages that you are sure you are not going to use.

### To specify languages for run-time 
This could maybe be handy to block languages/enable languages for the request handler. Use the `supported-languages` command argument. i.e.
`java -jar photon-0.1.2.jar -supported-languages nl,en`
to use the nl and en language tags (defaults to en when no lang is specified).

**However...**
When testing this functionality, I noticed that the order of results was different between `lang=en` and `lang=nl`. After some debugging I noticed that it was the same on all the previous enabled languages `(en,fr,it,de)`, but different on the `nl` tag. 

I found out this was because I didn't update the `mappings.json` which is used on import, to specify collectors for languages. This should be dynamically changed too, when specifying `nominatim-import-languages`, which leaves this PR **not finished**. 

### Thoughts? 
Thoughts & discussions are very welcome, on the code I wrote and on how I/we could tackle this problem correctly. 

### Things to do: 
- [x] Make mappings.json dynamic somehow
- [x] Fully test the changes
- [x] How would we handle the problem when `supported-languages` has specified a language that doesn't exist in the data

**PS.** I also added specific Dutch postcode checking to this PR, which may help other Dutch users of Photon. This filters out double `highway` names who are part of the same street. In The Netherlands, a street can have different postcode letters (i.e. 6532RA and 6532BE could be the same street). The numbers however, stay the same. So to avoid clutter, I filter results that have the same postcode number AND name. 
Yeah I thought about it to purely use the json package, which would be more consistent, but it would in my opinion be a bad effort/reward situation. It's easy to replace strings with the lang, while it would be cumbersome to do so with navigating through the json objects. Also, when the mappings change, much would have to be rewritten.