Hide upgrade history from global attributes on config page

Skipped the entry in code since applying a Limit removed the
upgrade history when calling the attribute methods in the
Upgrade history section later on the page.
Add ids to recorded upgrade entries to track success/failure

Installations and upgrades can run into issues that cause the
upgrade scripts to die. Add ids to track this history and aid
in future troubleshooting.

full_id: An id for multi-step upgrades from 'make upgrade-database'
The full_id tags each individual upgrade step as part of the larger
upgrade to unambiguously show that individual upgrades were run as
part of a full upgrade.

individual_id: An id to bookend the start and end of an upgrade
step and identify if a step failed to complete.

Adds Data::GUID as a guid generator.
Add before entry to insert actions

Add a before to the upgrade history to track progress on
possible failures and match the other before/after upgrade
history pairs. Capture the return code in the after entry.
Transform flat start/end events into an upgrade hierarchy
Store the actual return value data structure, to allow for reconstruction
Make the "after" stage merely metadata; ther is no need to repeat the data
Store schema and acl events as well
Recursively walk through the parsed history to display it
Reconstruct hierarchy on pre-GUID history records
Ensure that the Attributes table is big enough to contain the upgrades

Prior to RT 4.0.6, the Content column of the Attributes table was only
capable of holding 64k, being a BLOB or TEXT column (which it was
depends on if it is prior to 3.7.87).  If there are a large number of
upgrades which run prior to the 4.0.6 upgrade step which fixes this, the
base64'd data may overflow, and truncate the upgrade history.

Ensure that the first command run in the upgrade process is the relevant
ALTER TABLE to increase the size of the Content column.  This is only
relevant on mysql (see e249f67), and only if the initial version of the
upgrade is prior to 4.0.6.  If rt-setup-database is run more than once,
the ALTER will be idempotent.
Note the upgrades that did not complete
Merge branch '4.2/fixup-version-history' into 4.2-trunk