Patch - Critical Bug Fixes, Enhancements, and Code Cleanup

This project doesn't seem very active, but the functionality is exactly what I needed. Unfortunately, the filter module was failing when it tried to parse against my personal installation of MediaWiki (in spite of updating to the most recent version, to be safe). In looking into the problem, I found a number of issues with the code, both major and minor. I've attached a patch, which includes all the modifications I made to get the module to a point where it was useful to me. The patch includes the following changes:

1. The unserialize call was failing for most text I tried to parse. I added a couple of new preg_replace statements to properly escape the MediaWiki-parsed text before it gets unserialized.
2. In some situations MediaWiki adds Javascript to the parsed output, such as when a table of contents is included on a page. This added Javascript was almost always causing the call to unserialize to fail. While it might be desirable to include an option to entirely strip such Javascript, for my purposes I needed it included, so instead I added another couple of preg_replace statements to base64 encode the Javascript before unserializing, and then decode it again afterward.
3. The logic that handles the "Prevent MediaWiki links" option and the "Prevent MediaWiki images" option was inverted, so that links were prevented when the images option was selected, and vice versa. The conditional code was changed to correct this.
4. The code to prevent MediaWiki links from parsing was failing when there was more than one link to parse. For example, if you passed the following wiki text through the preg_replace statement: This wikitext has [[One Link]] followed by a '''phrase in bold''', followed by [[Another Link]]. It was being returned as: This wikitext has <nowiki>[[One Link]] followed by a '''phrase in bold''', followed by [[Another Link]]</nowiki>. As a result, the links weren't being parsed by MediaWiki, but neither was any text that came between the first link and the last link. To correct this, the .* item in the pattern was made lazy by adding a question mark.
5. The "Prevent MediaWiki links" option, if selected, was unnecessarily preventing links within the same page (links to anchors), even though they would always parse correctly. The preg_replace pattern was modified to allow these to parse.
6. The "Prevent images links" feature was not useful, because it was trying to prevent [image:] style links when MediaWiki uses the normal link construct [[image:]] instead. In addition, the option was not preventing the capitalized [[Image:]] syntax from being parsed. Furthermore, Mediawiki has since deprecated the [[Image:]] tag in favor of the general file [[File:]] tag, and I could see no reason why one would want to prevent file tags without preventing the related media [[Media:]] tags. Finally, the preg_replace pattern being used suffered from the same problem as the general link replacement pattern, in that the .* item needed to be made lazy to work for more than one match. The preg_replace statement was modified to correct for all of this.
7. In light of the changes to the "Prevent image links" feature, it was now mutually exclusive with the "Prevent MediaWiki links" option, since that option would already prevent the [[Image:]] links from being parsed. In addition, the description for the "Prevent image links" option needed to be updated to reflect that it affected [[File:]] and [[Media:]] tags as well. In the configuration menu for the filter, the "Prevent image links" and "Prevent MediaWiki links" options were modifed to be radio buttons (grouped in a new fieldset), and their descriptions were updated. A screenshot is attached that shows the changes to the filter's admin interface.
8. A number of minor spelling and grammatical mistakes were corrected.
9. A number of lines of code were modified to bring them into line with Drupal coding standards.

Although this patch only affects the mediawiki_api_filter sub-module, the patch should be applied from the base mediawiki_api directory (which I believe is the desired behavior), not from the sub-module directory.