MDL-44141 Completion: System updates data during restore

The completion system has code which is supposed to prevent it
updating completion status while grades are being restored. This
code was a nasty hack and had not worked for some time. As a result
completion dates were restored incorrectly.

This commit implements a 'proper' way to find out if a restore is
currently running, replacing the previous hack.
MDL-44070 Conditional availability enhancements (1): availability fields

Adds a new field 'availability' to the course_modules and
course_sections tables. This will be used to store JSON format
data about a tree of availability restrictions.

Includes changes to modinfolib so that the new fields are available,
and to the editing forms so that they can be entered and modified.
There are unit tests for the back-end (modinfolib).
MDL-44070 Conditional availability enhancements (2): subsystem/plugin

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).
MDL-44070 Conditional availability enhancements (3): API/tests

Implements the new availability/plugin API. This represents a
Boolean tree structure that controls the availability of an
item.

In this commit, the new API is not yet connected to the rest of
Moodle, so it doesn't do anything yet.
Backup/restore support
MDL-44070 Conditional availability enhancements (5): conditions

Includes all the conditions that were in previous Moodle versions:

* Date
* Grade
* Completion (of another activity)
* User profile field

Also includes conditions that are used to reimplement
groupmembersonly:

* Grouping
* Group

For each condition, the component plus unit tests are included.
MDL-44070 Conditional availability enhancements (?): core access

Changes core code to use new API instead of the old one when
checking user access to activities and sections.
MDL-44070 DB upgrade!!!!
MDL-44070 Conditional availability enhancements (?): remove old db

Deletes the database tables and fields that were used by the old
system and are no longer needed.
MDL-44070 Quiz: Remove groupmembersonly check on override page

The quiz override page does checks related to the groupmembersonly
setting so that it can avoid showing users (or show them as not
'active') if they don't meet that requirement.

While this may be a logical thing to do, it does not fit well
with the new API. There are also other ways that users could be
configured not to access the quiz which were not taken account of.
I have discussed this with Tim and he thinks these checks are not
necessary.
MDL-44070 Conditional availability enhancements (?): deprecate old lib

The old conditionlib.php, which is replaced by the new availability
API, has been deprecated.

* Code which uses the key functions (is_available,
  get_full_information) should still work. These now show
  deprecated warnings and then pass through to equivalents in the
  new API.
* I have created new unit tests for these functions.
* The old language file has been removed (reused strings hopefully
  moved with AMOS).
* Most other functions throw exceptions because it was impossible
  (due to fundamental API differences) or difficult to reimplement.
* I don't really expect that non-core code (outside unit tests) will
  have used any of the other functions.
MDL-44070 Conditional availability enhancements (?): Core changes

This commit contains changes required to make core Moodle (and
included plugins) integrate with the new availability system
instead of the old one. This includes making code handle the
following changes from previous commits:

* Removal of availability tables course_modules_availability,
  course_modules_avail_fields, course_sections_availability,
  course_sections_avail_fields.
* Removal of availability fields showavailability,
  availablefrom/until, and (on sections) groupingid.
* Removal of groupmembersonly.

In general the changes in this commit are not intended to alter
behaviour, except in the parts where the old system was removed
from the user interface.
MDL-44070 Backup/restore: Convert legacy data
Upgrade fix
MDL-44070 Workshop: Remove groupmembersonly checks

Logic relating to allocating users and showing lists of participants
used to take the 'groupmembersonly' flag into account.

I have changed the code so that it behaves as if
enablegroupmembersonly (which was always listed as an experimental
feature) had been turned off.

This will cause the following changes to behaviour:

Manual assignment:
* If groupmembersonly was enabled before, the list of potential
  users (under 'Manual allocation') would include only users who
  are in groups. Now it includes all enrolled users.

Random assignment:
* If groupmembersonly was enabled before, AND the assignment is
  set to 'no groups' mode, AND you choose the 'partipants can
  assess without having submitted anything' option, then the
  random allocation system would previously not allocate
  assignments for review to users who were not in a group. Now
  it will allocate to these users, even though (because of
  groupmembersonly) they cannot access the activity.

Note: Both before and now, it is possible for random assignment
to allocate assignment to users who cannot access the activity
for other reasons e.g. if there is a user profile condition.