Translatable strings for payment types

[1ec5]

Added human-readable, translatable strings for the most common payment types that are documented on the payment key’s wiki page. There are a great many payment:* subkeys, including plenty that are valid but undocumented, but this PR doesn’t attempt to enumerate them all. The subkeys omitted from this PR will continue to appear in the menu but as a raw value rather than a pretty-printed one.

I included most subkeys used at least 1,000 times according to taginfo. However, I omitted the following subkeys based on guidance on the wiki:

• none is discouraged because setting it to yes ambiguously means free of charge (fee=no) or cannot be purchased.
• others has to be set to no, but the multiCombo field type only allows subkeys to be tagged yes.
• bitcoin and bitcoincash are discouraged in favor of the currency:XBT and currency:BCH keys, respectively.
• mobile_phone is ambiguous; it variously means phone, sms, or app.

It remains possible to tag these subkeys, since the multiCombo field is freeform, but the field wouldn’t encourage the use of these subkeys.

[1ec5]

Strings for Taiwan’s ep_easycard and ep_ipass systems include the official Chinese name to avoid confusion with the Easy Card and I-PASS systems in the United States.

[1ec5]

These labels may seem trivial, but they’re properly capitalized to make the raw key look more presentable, and some of these brands have different official names in other languages or scripts.

[bryceco]

The subkeys omitted from this PR will continue to appear in the menu but as a raw value rather than a pretty-printed one.

Is that really how multiCombo works? It combines values from taginfo with the explicitly defined values?

[1ec5]

It’s how the combo field type works, for example Surface:

So far, no semiCombo field has had strings added to it, so I’m not 100% certain what’ll happen, but I’d expect it to behave similarly. However, I noticed that iD’s implementation of multiCombo doesn’t seem to be using the strings, for example Cuisine: #252 (comment). It might be related to the missing translations in openstreetmap/iD#8600.

[bryceco]

I was using the built-ins when available, or tagInfo if not, but didn't think to union them. Thanks!