Better support for placeholders

As of now, HTML and MessageFormat placeholders are said to be supported as "optional placeholders". (which, as we found, are not even always recognized).

With ICU MessageFormat strings, the current implementation is somewhat troublesome for messages having "nested" texts, such as when used with "select", "selectordinal" or "plural". The problem is that actual text to be translated is also contained inside the curly braces, as in this example:

{gender, select, male {He} female {She} other {They}} is your {count, selectordinal, one {#st} two {#nd} few {#rd} other {#th}} opponent.

When translated, OneSky finds two placeholders as big blocks. Upon translation, these blocks however must change, and this then issues a warning by OneSky due to "missing" placeholders. For instance, a correct German translation of the message above would be:

{gender, select, male {Er ist} female {Sie ist} other {Sie sind}} dein {count, selectordinal, =1 {erster} other {#.}} Gegner.

Basic handling of these placeholders should be:

• To understand that only the first identifier in the curly braces (before any punctuation) is the name of the placeholder, and thus check for missing placeholders only based on that identifier. This would work not only for MessageFormat but also for syntactically similar formats such as .NET format strings, which are in the form {1}, {1:f}, {1,8} or {1,8:f}
• To understand that nested curly braces switch back to "text mode", as seen in the example above. Note that formatting according to ICU MessageFormat may be nested, e.g. these text blocks can contain further format blocks.

Extended handling could include:

• To check that the "select" placeholders have the same options as in the base language.
• To check that the "plural" and "selectordinal" placeholders provide exactly the correct forms for the target language as per CLDR (as shown in the example above), with tolerance for static numbers (e.g. =1 in the German translation above).