Replace cldr by intl

[goldim]

This is my first try to move qooxdoo from CLDR to Intl API and not final I think. This allows us to get rid of big dependency which weights too much (500 MB). During migration I encountered bunch of problems, questions and ambiguities which I tried to solve on my own. And that's why I am asking you help me to change some of my solutions if that's required. Also I've created a discussion but didn't see a big involvement. No problem, I think the PR is right place. I've added tests for most methods which have not been tested. I would like to emphasize that some solutions via Intl API are elegant if you look at methods like getStartWeek, isWeekend, getWeekendStart, getWeekendEnd and will notice that there are no hardcoded values and exceptions. But Intl API has some disadvantages. There are following moments which I would like to clarify with you:

• [ ] 1. There is no quarter part like Q, QQQ and so on. Fortunately in qooxdoo there are two cases: yQ and yQQQ. First one has only one exception and I just hardcoded. The second one is much more difficult and has a lot of different variants. I also hardcoded them but didn't count child and parent locale. If it is required I will added them too. For example de_DE has a parent de and de_DE may have different yQQQ format for example.
• [ ] 2. The calendar type, in current qooxdoo implementation there are next algorithm we just take first child in array (0-index) but I doubt if that's right way because for example if I take chinese locale zh and check what it takes: "Buddhist calendar". To be honest I didn't find a solution to detect what calendar is most suitable for a locale. There is some functionality but it doesn't work in Firefox (getCalendars function). I would like to just use Gregorian calendar by default and add calendar method argument.
• [ ] 3. I removed most of CLDR mentions in the code and renamed methods but not all. Most of left ones are in compiler files. If required I rename and remove them too just tell me.
• [x] 4. There is cldr_ prefix I decided to leave it because of BC. There is a translate method which uses the prefix. I can't remove it but may rename it for example to intl_.
• [x] 5. I changed some tests for examples: this issue
• [ ] 6. Some expected values of getDateTimeFormat differ from CLDR implementation. For example for yM format of de_DE there is M/y but Intl API results only MM/y. I will try to find why it is. Other cases work like in CLDR implementation.
• [x] 7. For example Intl methods get locale de-DE as argument but qooxdoo methods get de_DE (dash instead of underline). I introduced a private method in two classes which transforms locale (they are duplications). I would like to get rid of the duplication but don't know what common class or entity will have this method. Maybe qx.locale.Manager.
• [x] 8. Didn't rebuild and committed npm-shrinkwrap.json. Should I?
• [x] 9. I added myself as author in source head but didn't change it overall.
• [x] 10. Intl.Locale doesn't work in 123 version of Firefox. For BC should be used old implementation.

[hkollmann]

8. Yes you should rebuild and add npm-shrinkwrap!

[goldim]

@hkollmann Fixed.

[goldim]

Just noticed that Intl.Locale is only supported since 124 version of Firefox and got failed in 123 of Ubuntu. I think to back old implementation of some methods.

[derrell]

Unfortunately, I have no way to test this, as I have almost no experience with localization, and only the most basic of usage of it in my apps. I'm concerned, however, about the list of variants that aren't covered by this change. It's very likely to affect some users. My suggestion is to mark as deprecated, in the upcoming release of 7.x, as many of the things that are known to be issues with the new implementation as possible, and then actually release this change as part of 8.0. Some users will likely encounter non-BC changes that will require altering their code.

Since this PR is marked as "do not merge - v8", I will approve this PR as is. I added the additional "do not merge" tag just in as an added warning, probably not necessary, but doesn't hurt.

[goldim]

@derrell it could be tested with our apps like widget browser for example. To see if the localization works set other locale and see how a datefield calendar is changed. Btw I can not fine an demo application in which you could change locale or country. I remember there were flags of 5 or 6 languages.