Base monetary locale on system support

Currently, the selection of locales for the monetary locale is based on the l10n directory's contents (much like the UI language choices). This is bad and the cause of quite a lot of issues/misunderstandings, as we fall back to system-provided monetary locales, not define our own ones.

We should base the drop-down on the list of locales actually supported in the system; this way we'll know that the setlocale() calls with actually work and provide the right monetary results.

This approach should be checked for all setlocale() calls in CiviCRM; i.e., whether we actually try to set a given locale that we know the system should support, or are we trying to set it blindly, based on l10n contents.

(Alternatively, we can provide monetary locales - decimal delimiter and thousands separator - for the languages that we offer and skip setlocale() calls altogether.)