The function calendar_get_default_courses is responsible for loading all variants of calendar
course lists.

1 the list of courses that the current user will see events for in the site calendar.
2 the list of courses the current user will see when they are looking at a specific course calendar.
3 the list of course calendars the current user can create / edit events in.

When loading courses for the course filter on the calendar, we only need the id and shortname.

Consolidate the logic for the list of courses an admin will see in the calendar.

They will see all courses if calendar_admincanseeall is enabled.

They will see only courses they are enrolled in of calendar_admincanseeall is not enabled.

They will also see the current course, if they are admin and it is not already in the list.

This applies to the course selector and the create and update event forms.

The calendar link in the navigation block has also been changed to link to the current course calendar instead of the global
one.

The property courseid and groupid might not be set, so if updating,
use the existing value if a new value wasn't specified.

It's quite common to have more than 50 events in a calendar month, but
we do not want to change the default value when the API is called in
other ways.

This is no longer used and should be deprecated.

This commit adds a set of templates for the calendar month block, and
the events filter. The same data exporters used in the main calendar
view are utilised and the same logic.

Some additional data was added to the exporters, and in the long term
this will be used in the main monthly view so I did not feel it was
prudent to strip it out into a different view of the model.

AMOS BEGIN
 MOV [monthnext,access],[monthnext,calendar]
AMOS END