Add optionsLocationSet for per-option combo field geo-scoping

[julcnx]

This came out of a discussion on openstreetmap/id-tagging-schema#2332, where a maintainer asked whether a single surface combo option (laterite, a tropical soil type essentially absent outside a specific belt of countries) could be scoped to only the regions where it's actually relevant, rather than showing in the dropdown everywhere. Field-level locationSet already exists for hiding a whole field by region, but there's no equivalent for a single option inside a shared combo field like surface, which is used across most highway presets globally.

This adds optionsLocationSet, a map from option value to a locationSet object, following the same {include, exclude} shape as the existing field-level locationSet. An option with no entry in the map is offered everywhere, same as today.

A few design notes:

• Kept separate from strings.options rather than nested inside it. Strings go through the translation-string extraction pass in build.js and end up in a different output artifact (the translation bundle), so geo data placed there would either get lost or incorrectly ship inside a translated-strings file. optionsLocationSet stays untranslated and flows straight through to the built field data, the same path the existing field-level locationSet already takes.
• Added validateOptionsLocationSet() to catch a key that doesn't match a real option value (typo protection), mirroring the existing validateTerms() validation pattern.
• Test fixture uses a chalky water-quality option scoped to include: ['GB', 'FR'] / exclude: ['GB-NIR'], chosen because it's a real-ish parallel (chalk streams/geology are heavily concentrated in southern England and northern France, and Northern Ireland's geology doesn't have them), rather than an arbitrary example.

This is the schema/build half of a three-repo change. A companion iD PR would teach combo.js to actually filter the option list using this data (it already has the exact plumbing for whole-field locationSet filtering in modules/ui/field.js, this reuses that same locationManager/locationSetsAt() mechanism per-option instead of per-field), and a follow-up id-tagging-schema PR would apply optionsLocationSet to laterite once both land. Opening this piece first since it's the smallest, self-contained one and unblocks the other two.

Happy to adjust the shape or approach if you'd prefer something different, this is very much a proposal, not a claim that it's the only way to do it.

[tordans]

This Repo was merged into https://github.com/openstreetmap/id-tagging-schema/pulls
It will be archived soon.

[julcnx]

Ah, missed that this repo's being folded into id-tagging-schema, thanks for flagging. Will pick this up directly in id-tagging-schema instead, and will hold off on that too until the format question on #2493 settles, per the discussion on openstreetmap/iD#12657.