Joomla! Update fails on hosts with an unwritable logs directory

# Overview

**Note**: See Joomla! Issue Tracker item [00000](http://www.example.com) Please enter your test results there, not in this Pull Request on GitHub, prefixing your message with `@test`. Thank you.

## Technical analysis

### BUG #1

Updating Joomla! is impossible on servers which have a reserved, unwriteable, system folder called `logs`. All Plesk-based servers and certain hosts put a directory called `logs` inside the public web root. They use it to store Apache log files. Since this directory is owned by a system user and has strict permissions (0700, 0750 or 0755) it is not writeable by PHP.

Joomla!'s update packages have a folder called `logs` with a sole `index.html` file in it. When the update archive extraction reaches that file the update hangs and the user is left with a partially updated, bricked site. As the users cannot make this directory writeable by any means, they end up with a site that is impossible to update.

This Pull Request modifies the archive extractor (`administrator/components/com_joomlaupdate/restore.php`) to ignore unwriteable files in the `logs` directory, allowing the update process to continue.

### BUG #2

Moreover, logging was added recently to com_joomlaupdate. However, if the log directory is not set in Global Configuration or if it's set to an unwriteable directory the failure to write a log file results in an error message and inability to update Joomla!. This is just plain wrong, as logging is an *optional* feature and its failure MUST NOT block the update of the CMS. This PR wraps the JLog::add lines in com_joomlaupdate with a try/catch statement to effectively ignore any logging errors and allow the site to be updated.

# Reproducing the bug and testing the PR

## Reproducing the bug

* Install a new Joomla! site based on the latest master branch
* Go to Components, Joomla! Update and click on Options
* Set the Update Server to Custom URL
* Set the Custom URL to http://akeebatest.s3.amazonaws.com/fakejupdate/list.xml
* Click on Save & Close. A new version 3.2.2 is detected. DO NOT TRY TO UPDATE JUST YET.
* Make your site's `logs` directory unwriteable. IMPORTANT: Changing the permissions IS NOT enough! com_joomlaupdate will try to fix the permissions if it can. You are advised to change the directory's ownership to root (Linux, Mac OS X) or Administrator (Windows). Then give it 0700 permissions (Linux, Mac OS X) or remove everyone's access except Administrator (Windows)
* Go back to your site and try to update to version 3.2.2.
* You get an error message that the log could not be opened. BUG #2 CONFIRMED. 
* Create a new top-level directory on your site called log-ok and make sure it's writeable by PHP (e.g. give it 0777 permissions – yes, 0777 is the number of the beast but this is just a test site which we'll delete afterwards)
* Go to Global Configuration and set the log directory from ...../logs to ...../log-ok (the dots represent the existing pathname already displayed)
* Go back to Components, Joomla! Update and start the update
* The package downloads and starts extracting.
* The update stops somewhere between 3% and 4% with an error saying that ...../logs/index.html could not be opened for writing. BUG #1 CONFIRMED.

## Testing the PR (true positive testing)

Let's make sure the PR fixes this issue.

* On the site you have already created delete tmp/joomla.zip
* Go to Global Configuration and set the log directory from ...../logok to ...../logs (the dots represent the existing pathname already displayed)
* Go back to Components, Joomla! Update and start the update
* The package downloads and starts extracting. FIX FOR BUG #2 CONFIRMED.
* The update completes. FIX FOR BUG #1 CONFIRMED.

Note: you will get a warning similar to the one [in this picture](https://www.dropbox.com/s/y0dzm1e24dvephf/Screenshot%202013-11-22%2015.27.30.png). This is expected, as my fake update package lacks a few files.

Also note that the Joomla! version is still 3.2.1. Did I mention enough times already that my update package is fake? :)

## Cross-testing the PR (false positive testing)

Let's make sure that making a different directory unwriteable still leads to an error. This is desirable, as it indicates ownership/permissions issues on the site.

* On the site you have already created delete tmp/joomla.zip if it still exists
* Make your site's `cli` directory unwriteable. IMPORTANT: Changing the permissions IS NOT enough! com_joomlaupdate will try to fix the permissions if it can. You are advised to change the directory's ownership to root (Linux, Mac OS X) or Administrator (Windows). Then give it 0700 permissions (Linux, Mac OS X) or remove everyone's access except Administrator (Windows)
* Go back to Components, Joomla! Update and start the update
* The package downloads and starts extracting. It throws an error halfway through about not being able to write a file in the cli directory. FALSE POSITIVE AVOIDANCE TEST SUCCESSFUL.

# Project management information

## Backwards compatibility

Backwards compatibility is not affected.

## Information to developers

None is required. This PR only modifies code used internally by Joomla!. Furthermore, the public API of the code is immutable after the application of this PR

## Severity of this bug

Medium-High as it makes it impossible to update Joomla! on several popular hosts.