This introduces a new function called tpl_flush() which should be used
by template authors in favor of the PHP flush() method.

	This patch adds support to include plugin tests in the
	DokuWiki testsuite. Plugin tests are located in a dedicated
	directory _test/within a plugin directory. The naming
	convention of the test files follows the one used in
	DokuWikis testsuite.

		<plugin>/_test/*.test.php 	-> single test
		<plugin>/_test/*.group.php  -> group test

	The plugin tests are accessible via the web interface
	of the test suite and via the cli interface. It is recommend
	to bundle plugin test in a plugin group test. The webinterface
	also allows to run all plugin tests at once.

	Test files must include:

		<dokuwiki>/_test/lib/unittest.php

	Example Test:

	require_once(DOKU_INC.'_test/lib/unittest.php');
	class plugin_test extends Doku_UnitTestCase {
		function test() {
			$this->assertEqual(1,1);
		}
	}

	Example Group Test:

	require_once(DOKU_INC.'_test/lib/unittest.php');
	class plugin_group_test extends Doku_GroupTest {
		function group_test() {
			$dir = dirname(__FILE__).'/';
			$this->GroupTest('plugin_grouptest');
			$this->addTestFile($dir . 'plugin.test1.php');
			$this->addTestFile($dir . 'plugin.test2.php');
			$this->addTestFile($dir . 'plugin.test3.php');
		}
	}

	At the moment unittest.php contains only two
	meta classes so plugins tests don't have to inherit
	from the simpletest classes.

	This patch should be treated as intermediate step to
	allow for plugin tests. The testsuite wasn't designed
	to include plugin tests. It should probably be refactored
	at a later point.

Plugins may return false in isSingleton to let plugin_load return a new
instance every time it is called.
Renderer plugins are not loaded with $new set to true, but instead specify
themself that they are not singletons. This behaviour allows the odt renderer
to keep working (see #1598).

* Popup now shows up relative to the link, not the mouse position
* Easier handling of mouseout’s bubbling
* Factor out popup creation to allow plugins to use it

50e988b1 accidentally stopped act_dispatch from calling act_edit for locked
pages, thus showing a generic »page not writable« message instead of a
page lock message.

explode converts $string (false) to string ("") and returns it if $delimiter is
not found, therefor looking for the key "" in metadata array.

Each searches on the wiki use this function. Scanning the index directory eachtime is time consuming with a constant series of disk access.
Switching a normal search to use file_exists 1 or more times, and not readdir all the directory.
Switching a wildcard search to use a lengths.idx file containing all the word lengths used in the wiki, file generated if a new configuration parameter $conf[readdircache] is not 0 and fixed to a time in second. Creation of a new function idx_listIndexLengths to do this part.

This commit adresses two issues:
  * rawWikiSlices used to drop the first byte of the suffix (usually a newline,
    but custom section edits may not be bound to newlines)
  * con used to insert way too much newlines: the newline that got
    dropped by the bug in rawWikiSlices and one additional newline in prefix
    and text each if they are not terminated by a newline. Now con only inserts
    newlines if there are absolutely no newlines between prefix and text and
    text and suffix.

It seems that the 0x0B Vertical Tab character breaks the PHP
XML parser. This workaround replaces the char with a space
before parsing. Not ideal but good enough for now.

The hash option did not hash the correct content for the
found media files. This causes troubles in the sync plugin
http://github.com/splitbrain/dokuwiki-plugin-sync/issues#issue/1

When the page is not editable or the section info is out of date, a custom
editor should not be used.

Before this patch the temporary filename was the uncleaned id. This
allowed everyone with upload-privileges (on the whole wiki) and XML-RPC
privileges on a XML-RPC-enabled DokuWiki to (over)write any file PHP is
allowed to write with any content he wants. If you have XML-RPC enabled
and users with XML-RPC and upload privileges you don't trust in a way
you would allow them to write any file PHP may write, consider this as
an important security fix. By default XML-RPC is disabled, so if you
don't know what I'm talking about you are probably not affected by the
problem.