Post-upgrade script issues leading to com_postinstall errors after upgrade to Joomla! 3.2

# Overview

**Important**: See Joomla! Tracker item [???]()

This PR fixes two issues with the post-upgrade script (JoomlaInstallerScript) that have been the root cause of bus reported in the Joomla! forum:

* Post-installation Messages component causing errors after upgrade
* The updateAssets() method causing a Fatal Error

# Technical analysis

## Post-installation Messages component errors

The most common symptoms are one of the following messages:

* `An error has occurred.  0 SQL=SHOW FULL COLUMNS FROM abcd_postinstall_cpanels`
* Call to a member function getInt() on a non-object in .../administrator/components/com_postinstall/models/messages.php on line 37

These errors have actually nothing to do with the code we include in Joomla! 3.2. These errors occur when the user has installed a very old version of FOF (1.x) in his site, most likely as the result of installing a very old version of a FOF-powered component in a Joomla! 2.5 site. FOF 1.x was never compatible with Joomla! 3, therefore the site must be upgraded from Joomla! 1.6, 1.7 or 2.5 for this error to occur.

The problem is that FOF 1.x had a flat layout, each one of its classes being a single file in the root of the libraries/fof directory. FOF 2.x moved to a PSR-0 scheme, just like Joomla! Platform, with each class file being in a package in its own sub-directory inside the libraries/fof directory. The FOF autoloader supports both conventions and always loads the legacy libraries first. The solution employed by FOF 2.x components is to remove the FOF 1.x files upon installation. This is not done when upgrading to Joomla! 3.2 as the code to do that was missing from JoomlaInstallerScript. This PR adds the missing lines to prevent this error condition.

Note: FOF is the framework selected as the Joomla! RAD Layer. The two names are used interchangeably.

## The updateAssets() method causing a Fatal Error

The updateAssets() method was referencing the $db object in the final if-block which is supposed to perform roll-back in case of a failed update. However, the $db object wasn't defined in the scope of the method, leading to a fatal error.

To the best of my knowledge nobody reported it, presumably because a failed installation causes more grave issues than a fatal error. It was an easy fix, so here you have it.

# Further information

## Backwards compatibility issues

**None**. This PR does not affect the public API and doesn't even include any code. It merely enumerates the files to be deleted and defines the missing variable.

## Developer information

**None**. This PR does not affect the public API.

## Testing instructions

Due to the conditions leading to this issue it is a far cry providing test instructions without referencing my own software, usually considered a cardinal sin in this project, but there you have it anyway.

One could follow this procedure to reproduce the issue:

* Create a new Joomla! **2.5** site
* Install []Admin Tools Core 2.2.10](https://www.akeebabackup.com/download/admintools/admintools-2-2-10.html)
* Upgrade to Joomla! 3.2
* You will get one of the aforementioned error messages

One could follow this procedure to reproduce the fix:

* Create a new Joomla! **2.5** site
* Install []Admin Tools Core 2.2.10](https://www.akeebabackup.com/download/admintools/admintools-2-2-10.html)
* Upgrade to Joomla! 3.2, replacing the administrator/components/com_admin/script.php file of the upgrade package with the one from this PR
* You will not receive any of the aforementioned error messages

I know that testing it is very hard. Sorry, folks, we have not yet been able to provide simple test instructions for issues affecting the post-update script :(