[Development] Calendar Systems proposal

[Soroush Rabiei]

> Now question is that: witch form is preferred? Will be case (1) break Qt
> rules?

I don't know about QML and it'd design principles, but I like option
3. Though it must take that calendar instance as second argument I
suppose:

    var out = date.toString("yyyy/MM/dd", Qt.JalaliCalendar); // Is
this possible?

Speaking of the API, I wish to share an idea about not to put calendar
implementations in a plugin subsystem.

There are differences between those concepts that are implemented as
plugins and calendars. A calendar system is not an image format nor a
database implementation. There will be no new calendar (at least, it's
unlikely to have a brand new calendar) and there will be no newer
versions of existing calendars. What is the point of having calendars
as plugins? And we have to keep QGregorianCalendar everywhere after
all... And we will have the problem of instantiation. While plugins
have no public header, then how we are supposed to use them in code?
Like this:

    QDate d;
    d.setDate(y,m,d,QCalendar::fromName("jalali"));

Or maybe:

    d.setDate(y,m,d,"jalali");


Let's add all calendar systems that do have locale information in
CLDR, and make all of them configurable as to be built or not, except
QGregorianCalendar. Then decide on a default subset of calendars to be
compiled into qtbase. That will be something like:

+----+-----------------+--------------------+------------+--------+
|No. |Name             |Variant             |Configurable|Default |
+----+-----------------+--------------------+------------+--------+
|1   |Gregorian        |                    |No          |Yes     |
+----+-----------------+--------------------+------------+--------+
|2   |Islamic          |Astronomical        |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|3   |Islamic          |Civil (Algorithmic) |Yes         |Yes     |
+----+-----------------+--------------------+------------+--------+
|4   |Persian          |                    |Yes         |Yes     |
+----+-----------------+--------------------+------------+--------+
|5   |Hebrew           |                    |Yes         |Yes     |
+----+-----------------+--------------------+------------+--------+
|6   |Chinese          |                    |Yes         |Yes     |
+----+-----------------+--------------------+------------+--------+
|7   |Japanese         |                    |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|8   |Buddhist         |                    |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|9   |Republic of China|                    |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|10  |Coptic           |                    |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|11  |Ethiopic         |Amete Alem          |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|12  |Ethiopic         |Amete Mihret        |Yes         |No      |
+----+-----------------+--------------------+------------+--------+
|13  |Indian           |                    |Yes         |No      |
+----+-----------------+--------------------+------------+--------+

For historical calendars, Qt users are unlikely to add marginal
calendar systems -> A reason to avoid plugin system. Though having
current schema, they can subclass QAbstractCalendar and add their
calendar (not as a loadable plugin) in their own code.