File readers

LU rewrite part 1: file readers

* Classes for PHP and JSON formats with tests.
* Factory class for creating suitable readers.
* Moved autoloads to separate file

Since 1.19 is LTS and supports PHP 5.2.3, I cannot use namespaces.
Instead, used LU_ prefix to avoid class name clashes.

Change-Id: Ic4f96df4e01fb2ff5b2904e19ea0d35865dc7406
I18n file finder

LU rewrite part 2: file finder parses the $wgExtensionMessagesFiles
and $wgMessagesDirs variables to list the components to be updated.

Change-Id: I946168fb6ed4f0fef4226ddab5704f9f2d8acc95
Fetchers

LU rewrite part 3: classes which can fetch files from local file
system or over the web. Since there is no standard way to fetch
directories over the web (design decision to be able to pick up new
languages when json files are used) I also implemented a special
fetcher for GitHub that downloads a list of files first and then
only fetches the files which exist.

Change-Id: Ib712553ea450ca1d8e0219e81dc5147fb53f2128
Updater class

LU rewrite 4: New main class which executes the file fetching, parsing
and combining the results.

Change-Id: Iba2bed79b2069b8b9a579d3759572def0363e4c3
Rewritten update script and configuration

LU rewrite part 5: The update.php was rewritten to be a maintenance
class and use the new helper classes. New configuration format for
repositories, which is not backwards compatible. Will use GitHub
as default as it provides the list of files in a directory,
needed for efficient fetching of json translations.

Cleaned up LocalisationUpdate class of now unused code.

Speed seems reasonable. With translatewiki.net like setup, speeds
were as following:

Local clones:
Saving 2866 new translations

real    1m26.045s
user    1m25.149s
sys     0m0.688s

From GitHub
Saving 2866 new translations

real    5m4.899s
user    1m38.182s
sys     0m1.788s

Updates could be further optimized by not fetching files which have not
changed a) since last update, b) from what is currently in use. Fix a)
would require to store what translations were updated for each file.

This extension fully supports json.
1) Extensions using json files are supported, picking up new languages
as they appear.
2) Core is easy to switch to json once it has been converted.
3) LocalisationUpdate stores updated translations in json format.

There are a few caveats, though.
4) Once core switches to json format, all users must update LU to keep
receiving updates. But they will need to update anyway because older
versions of LocalisationUpdate do not support json at all.
5) If an extension switches to json, we will not be able to provide
updates until its local checkout is updated to such a version:
LocalisationUpdate does not know about the switch and will try to fetch
the PHP shim, which does not have translations any longer. This is
usually okay, as the PHP shims support old MediaWiki versions; problems
might appear if the extension has other incompatible changes which
prevent updating.

I have tried to rewrite LocalisationUpdate in a way compatible with
MediaWiki 1.19, including being compatible with PHP 5.2.3. After
support for that version is dropped, some code can be improved to take
advantage of new features in PHP 5.3, mainly namespaces.

Change-Id: I21ce94ae2262d9c90132d21c4c9f8ebdd08a14ea
Fixed typo in update.php

Change-Id: I34ae376837fafb019d597a02b773e3e107ed0329
Merge remote-tracking branch 'origin/json-rewrite'

Change-Id: I146d20c133d3d0b607230e907c76423574e27dfe