MDL-18375 calendar: huge refactor of the initial patch

1) Moved the calendar types location to a sub-folder in the calendar directory.
2) Removed/moved language strings.
3) Removed calendar types that should be downloaded as plugins.
4) Removed a Non-English language pack for the Gregorian calendar type that
should be downloaded separately.
5) Removed custom files responsible for checking for updates and uninstalling
calendar types, which should be done by core.
6) Removed JS from the calendar_month block as there is no non-JS alternative
provided and the JS written does not make use of the YUI library to ensure
multiple browser support.
7) Removed code from the base class responsible for creating timestamps that
are saved in the DB.
8) Added PHPDocs.

Note: In the original patch we are editing core functions responsible for saving
time in the database in the calendar base class. This is very dangerous, we do
not want to touch these functions as it could cause a complete fubar of the
database. There are places we are forcing the use of the gregorian calendar as
we are passing dates generated by the PHP date function, where as sometimes we
pass dates from usergetdate (which was being overwritten to return the date
specific to the calendar). We can not expect third party modules to change the
calendar type depending on the format they pass to these functions.
MDL-18375 calendar: only display the YUI2 calendar when the Gregorian type is used
MDL-18375 calendar: moved the location of the calendar type select box when editing a course
MDL-18375 calendar: edited the calendartype column in the install.xml file and created an upgrade path
MDL-18375 calendar: refactored the datetime user field so that it now uses the calendar type system
MDL-18375 calendar: implemented the usage of the recently introduced automatic class loading
MDL-18375 calendar: created a test calendar type to use for PHPUnit tests and added tests
MDL-18375 calendar: renamed the userdate/usergetdate functions and changed them to abstract

Renamed the userdate/usergetdate functions in the calendar type to be more
descriptive and made them abstract to ensure developers implement this
functionality in their calendar type.

Also tidied up PHPDocs for these functions.
MDL-18375 calendar: PHPDoc tidy up as well as some other minor changes
MDL-18375 calendar: only display the choice of calendar types if there is more than one
MDL-18375 calendar: added the Gregorian calendar type to the standard list of plugins
MDL-18375 calendar: added condition to ensure calendar type exists before loading
MDL-18375 calendar: changed the name of the function factory to be more descriptive
MDL-18375 calendar: removed usage of the calendar type in the usergetdate function

The usergetdate function is not only used to display dates, it is also passed
to the function make_timestamp. This means users using another calendar type
other than Gregorian will generate incorrect timestamps which may be saved in
the DB or used to populate the date_selector and date_time_selector elements.
For example, when creating an assignment using another calendar type other than
Gregorian, the mod_form.php file calls $this->apply_admin_defaults() which uses
the function usergetmidnight to set the "Allow submissions from" date to today's
date and the "Due date" field to 7 days in the future. The usergetmidnight
function calls usergetdate which is then passed to make_timestamp. Since the
usergetdate function was using the calendar type's timestamp_to_date_array
function the date being passed to make_timestamp was not in Gregorian. So, when
using the hijri calendar the year 1434 was being passed which was generating a
large negative number as the timestamp which was then used to populate the date
fields.
MDL-18375 calendar: fixed issue when resaving the year in the datetime field causing the year to decrease

For example, a user may create a date/time profile field and set the 'Start year'
field to '2012'. Another user, using the Hijri calendar, may edit the name of
this field. They visit the settings page and in this case the date '1/1/2012'
is converted to '7/2/1433' in Hijri. So, the year '1433' is then displayed.
The user then changes the name of this field and saves the form. This is where
the issue occurs, as the date '1/1/1433' is converted into Gregorian, which
converts to the year '26/09/2011', so the year '2011' is saved in the DB, not
'2012'.