Improve searchability of optional fields

[quincylvania]

Fields do not always have the names users expect, see #5755 (comment). Now that there could be many fields in the "Add field" dropdown, we should make them easier to search:

• Match the field's tag key
• Add search terms array, like with presets

[eehpcm]

Maybe you shouldn't restrict which fields can be added to your preconceived notions of what is applicable. As I just noted in #5755 you can't add opening hours to toilets with "Add field".

Even if you expand the list to everything that is documented as possibly applying to a particular type of object, a mapper may have reasons to use something. So maybe not everything is in the drop-down list but maybe everything should be searchable. Or maybe not. Adding a cuisine to toilets is just wrong. :) But many things can have opening hours, and that's probably not the only field with more general applicability..

[quincylvania]

Maybe you shouldn't restrict which fields can be added to your preconceived notions of what is applicable.

@eehpcm I've thought a lot about this, and I think the biggest consideration is making sure casual mappers feel that any field that they can add is appropriate for the preset. To this end, we actually removed a lot of universal fields in 2.13.0 and manually added them to the appropriate features (see #5719). You can still add any tags you want in the raw tags editor!

A field like opening_hours makes sense for lots of businesses and facilities, but there are many other objects in OSM that it doesn't apply to (walls, power lines, mountains, rivers, counties, etc). I do appreciate you finding instances like opening_hours+toilets where fields are missing, and I encourage you to open issues and/or pull requests as you find them!

[quincylvania]

I did this. You can now add terms to fields…

{
    "key": "level",
    "type": "combo",
    "label": "Level",
    "universal": true,
    "terms": [
        "building floor",
        "deck",
        "storey",
        "story"
    ]
}

…and iD will use them when filtering fields.

For efficiency, only fields that could be searchable are translatable. Even so, this still adds lots of translatable strings to Transifex at once.