The patch moves the resolving logic from the renderer (where it should
not really be) to the plugin manager (controller). This is needed
because we will need the very same logic to be used at other places.

The actual loading of available updates info objects is moved back to
the plugin manager class. As we can now mockup the manager in unit
tests, this allows us to bypass the real \core\update\checker and have
unit tests for \core\plugininfo\base::available_updates().

Plugin info objects are owned by the plugin manager (composition
pattern). Even if the plugin manager is a singleton, we need to keep
explicit reference to the plugin manager that owns the plugin info so
that we can mock up things in unit tests.

Therefore this patch introduces a new property of plugin info objects
that holds the reference to the instance of the plugin manager that made
(and hence owns) the given info instance.

The only trouble here is with static methods of plugin info classes such
as \core\plugininfo\base::get_enabled_plugins(). In these cases, the
code keeps using the core_plugin_manager singleton. The solution would
be to pass the plugin manager instance as a parameter but that is not
worth of change for now, IMHO.

We can now override the plugin manager's methods in the testable
subclass while still keeping the singleton behaviour of it. The change
makes use of late static binding.

Before this patch, whenever core_plugin_manager::get_plugins() was
called, it always attached info about available updates. But this is
needed only in quite rare cases, such as when the admin is looking at
the Plugins overview and Plugins check screens. There is no need to load
this on other places and for non-admin users.

The patch removes the loading from the method
core_plugin_manager::get_plugins_of_type() and implements lazy loading
directly in the plugininfo classes so that it is loaded only when
\core\plugininfo\base::available_updates() is actually called.

This patch replaces all homegrown timezone
stuff with standard PHP date/time code.

The main change is the introduction of core_date
class that returns normalised user and server
timezones. From now on nobody should be using
$CFG->timezone or $user->timezone directly!

Other new features and fixes:
* admins are prompted for timezone during install
* editing of other users is finally fixed
* timezones are displayed in user profile
* new $this->setTimezone() in phpunit
* time locale is now automatically reset in phpunit
* timezone is now automatically reset in phpunit
* phpunit has Australia/Perth as default timezone

Stop silencing errors when including version.php

AMOS BEGIN
CPY [bestgrade,block_quiz_results],[bestgrade,block_activity_results]
CPY [bestgrades,block_quiz_results],[bestgrades,block_activity_results]
CPY
[bestgroupgrade,block_quiz_results],[bestgroupgrade,block_activity_resul
ts]
CPY
[bestgroupgrades,block_quiz_results],[bestgroupgrades,block_activity_res
ults]
CPY
[config_format_absolute,block_quiz_results],[config_format_absolute,bloc
k_activity_results]
CPY
[config_format_fraction,block_quiz_results],[config_format_fraction,bloc
k_activity_results]
CPY
[config_format_percentage,block_quiz_results],[config_format_percentage,
block_activity_results]
CPY
[config_grade_format,block_quiz_results],[config_grade_format,block_acti
vity_results]
CPY
[config_name_format,block_quiz_results],[config_name_format,block_activi
ty_results]
CPY
[config_names_anon,block_quiz_results],[config_names_anon,block_activity
_results]
CPY
[config_names_full,block_quiz_results],[config_names_full,block_activity
_results]
CPY
[config_names_id,block_quiz_results],[config_names_id,block_activity_res
ults]
CPY
[config_show_best,block_quiz_results],[config_show_best,block_activity_r
esults]
CPY
[config_show_worst,block_quiz_results],[config_show_worst,block_activity
_results]
CPY
[configuredtoshownothing,block_quiz_results],[configuredtoshownothing,bl
ock_activity_results]
CPY
[config_use_groups,block_quiz_results],[config_use_groups,block_activity
_results]
CPY
[error_nogroupsexist,block_quiz_results],[error_nogroupsexist,block_acti
vity_results]
CPY [worstgrade,block_quiz_results],[worstgrade,block_activity_results]
CPY
[worstgrades,block_quiz_results],[worstgrades,block_activity_results]
CPY
[worstgroupgrade,block_quiz_results],[worstgroupgrade,block_activity_res
ults]
CPY
[worstgroupgrades,block_quiz_results],[worstgroupgrades,block_activity_r
esults]
AMOS END

This commit introduces support to the LTI module for LTI 2.0.
As well as the initial commit the following changes were made
and then squashed into the single commit for integration:

* Fixed bug in services
  Fixed bug which limited characters allowed in values of template
  variables (e.g. vendor ID) in service endpoints.
  Changed language file to refer to tool registrations rather than
  tool proxies.

* Refactored service classes
  Moved classes relating to services into areas where Moodle will
  autoload them

* Ran code through code checker
  Removed all errors reported by the Code checker module
  excluding third-party OAuth.php file.

* UI improvements
  Mainly when adding an external tool to a course - fields which
  should not be changed for a selected tool are either hidden or
  disabled. Admin settings page now shows the Tool Registration
  name against a tool rather than the launch URL, and the
  registration URL replaces the GUID on the tool r...

Original issue - MDL-45916

Added pagination back in with some general fixes.

AMOS BEGIN
 CPY [override,mod_quiz],[override,gradereport_singleview]
AMOS END

This issue is a part of the MDL-47194 Task.
This issue is a part of the MDL-39707 Epic.

This issue is a part of the MDL-47194 Task.
This issue is a part of the MDL-39707 Epic.

This allows information to be dragged and dropped directly into a
form to be imported into the gradebook.

Learnwise was an old LMS that no longer exists. (Last reference found on
Google from 2009.) So we are removing the ability to import questions in
that format.

Credit goes to PJ King. I was trying to add unit tests for this new
behaviour but it turned out there are many hard-coded dependencies and
it's not easy to make the whole machinery support alternative location
of testable (fake) plugins.

This commit defines the new /availability root folder, with
/availability/classes, /availability/tests, and
/availability/condition where the condition plugins will live.
Condition plugin prefix is availability_, e.g. availability_date.

Rationale for this organisation:

1. I was originally going to put this in /lib/availability but
   it has been pointed out that putting even more junk in lib
   is probably bad.
2. 'availability' and 'condition' are the two names used in code
   to refer to this system ($CFG->enableavailability).
3. The prefix has to be short enough to allow database tables
   (although in practice I assume that condition plugins will not
   normally contain database tables).

The new API includes a Boolean tree structure that controls the
availability of an item.

AMOS BEGIN
 CPY [availabilityconditions,core_condition],[restrictaccess,core_availability]
 CPY [enableavailability,core_condition],[enableavailability,core_availability]
 CPY [configenableavailability,core_condition],[enableavailability_desc,core_availability]
AMOS END

Added missing capabilities and language strings

AMOS BEGIN
 CPY [choosereadme,theme_clean],[choosereadme,theme_more]
 CPY [configtitle,theme_clean],[configtitle,theme_more]
 CPY [customcss,theme_clean],[customcss,theme_more]
 CPY [customcssdesc,theme_clean],[customcssdesc,theme_more]
 CPY [footnote,theme_clean],[footnote,theme_more]
 CPY [footnotedesc,theme_clean],[footnotedesc,theme_more]
 CPY [invert,theme_clean],[invert,theme_more]
 CPY [invertdesc,theme_clean],[invertdesc,theme_more]
 CPY [logo,theme_clean],[logo,theme_more]
 CPY [logodesc,theme_clean],[logodesc,theme_more]
 CPY [pluginname,theme_clean],[pluginname,theme_more]
 CPY [region-side-post,theme_clean],[region-side-post,theme_more]
 CPY [region-side-pre,theme_clean],[region-side-pre,theme_more]
AMOS END

Centralise management of all types of cron tasks with registration, scheduling,
parallel task conflicts(blocking) and running once off tasks, all using an
administration screen.

This is a combination of several issues:

MDL-25502: Added "black magic" task allocator for cron
MDL-25503: Add step to cron to run all scheduled tasks
MDL-25504 cron: Refactor to use scheduler
MDL-25505: Add an admin interface to schedule tasks via cron.
MDL-25507: Add support for adhoc tasks.