Move mahara cron log files to /var/log/mahara/ so they can be kept separate from other content in /var/log

Turns out I got the table_column call wrong also. Needs to, like with everything else in xmldb, fully respecify the column. Now the view migration works in MySQL

XMLDB and MySQL conspired to make this a horrible process.

This change adds the ability to prevent the SQLException constructor from logging errors, which is used in init.php when attempting to load the config data and set default config values.

Removed a couple of unneeded debugging lines from the view migration. Made sure to make the block column of the view_artefact table not null after the upgrade, and clear out all the null rows

Ensure that two different composites of the same type can be displayed in the same view, by suffixing their variables/IDs with something random

Conflicts:

	htdocs/lib/upgrade.php

Make blocks with more than one artefact in them (as what happens with listself) be expanded to have all of them displayed individually. This fixes the last major problem with migrating view templates.

 * Up the memory limit to 64M. The 16M limit was hit when migrating a 600 view Mahara, so I don't imagine 64M will be hit in the wild
 * Move the installation of the blockinstancecommit event to before the view migration. This is so that such events can be fired safely by blockinstances that are being committed
 * Install _all_ of the blocktypes when upgrading

Only make sure about resume artefacts being in the block instance if the instance is _actually_ an entireresume blocktype.