Support plurals in Android exports

[toolstack]

Currently GP does not support plurals in Android XML files, however the standard does provide support for them.

[toolstack]

See some discussion here from the related PR.

[toolstack]

The main issue is converting the gettext plurals equations in to CLDR plural types.

There are a few issues:

• the current locales data seems to be outdated, of our plural entries that have corresponding CLDR data, ~46% of them do not match what is in the CLDR data (sometimes the equations are slightly different but sometimes the number of plurals is completely different).
• we support many locales that are not in CLDR, of the plurals that are not the default expression, ~21% do not have matching CLDR data (sometimes this is a variation on a local like Algerian Arabic which has the same plural as the "parent" locale).
• That leaves ~33% with which actual match between our gettext equations and the CLDR.
• All three of the above are only for locale's that have custom plurals (aka plural_expression != 'n != 1').
• There are many locales defined in CLDR that we don't currently support in GP.

The above cause 3 primary problems:

1. When the gettext expression doesn't match the CLDR data incorrect translations would be used in the Android XML files.
2. Any locale that doesn't have CLDR data won't be useable by Android (or any other format that uses CLDR as it's source for locales).

There's no easy way to map between the gettext expressions and the CLDR types, it might be possible if all of our expressions matched with the CLDR types, but even then the number of variations make it nearly impossible to do the mapping reliably.

My current thought about a solution is to do the following:

1. Add a cldr_order and cldr_unsupported property to the locale class.
2. cldr_order would be an array() of orders (probably a good time to revisit the variants issues).
3. The default cldr_order would match the default we currently use for the gettext expressions.
4. Review and update the plural_expressions in our locale data to match the CLDR data.
5. Manually set the cldr_order to match the CLDR data.
6. For any locales that are not in the CLDR data, manually create custom orders and add a cldr_unsupported = true to them so that in the future we can add them if the CLDR database is updated. We could also add a comment to the header when exported to indicate that it is currently not in the CLDR database.

The downside to the above is probably some pretty major breakage for some locales where the plurals expression is currently "incorrect". But that should probably be fixed either way.