Allow multiple access values per key in access manager

[mcliquid]

That was a lot of work, but I think I managed to solve it pretty well. The code is certainly not perfect, but so far it works in my tests. Please feel free to give feedback or test it!

What changed?

• Multi-select for all access keys now possible
• Clean OSM serialization (value1;value2)
• Existing values parsed correctly
• Overview shows only set values
• Intuitive removal of individual values
• Fixed dialog crash

Screen Record

Because of the video size available here: https://clip.place/w/uXmCrRNVeTTFmSqVGC1rom
I tried to cover most combinations.

Screenshots

Closes #651

[mcliquid]

After testing the new features here a few times myself, one more idea for further discussion:
Key-specific access values
Should the quest offer only a limited selection of values for certain keys? For example, the wiki explains that access=designated is not useful at all, that dismount should only be used for bicycle, or that use_sidepath should only be used for foot/bicycle.
To do this, I could perhaps create a allowedValuesByKey list in a separate accessValues.kt with permitted values per key.
For example:

val allowedValuesByKey: Map<String, List<String>> = mapOf(
    "access" to listOf("yes", "no", "private", "permissive", "permit", "destination", "delivery", "customers"),
    "foot" to listOf("yes", "no", "designated", "use_sidepath", "dismount", "permissive"),
    "bicycle" to listOf("yes", "no", "designated", "use_sidepath", "dismount", "permissive"),
    "motor_vehicle" to listOf("yes", "no", "destination", "delivery", "private"),
)

Of course, this would severely restrict the freedom of choice through strict requirements. If we trust our users, there is no need for this.

[mnalis]

If we trust our users, there is no need for this.

Yeah, probably no need. It would IMHO needlessly add complexity and restrictions.

And we need to trust them anyway, because if they don't know what specific keys and values (e.g. ohv or permit) actually mean, they are going to mess up the database in any case; restrictions or not.