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'.