This adds a new method that capsulates the access check that has to be
done to decide if an admin plugin's page should be shown to the user.
The default implementation is the same as before, relying only on the
forAdminOnly() method and the users' isadmin or ismanager status.

Admin plugins themselves can override the method to do additional
checks. In this patch, I added that to the usermanager plugin which will
only return true if the current auth backend can list users.

However the real idea behind this change is that the new method emits a
new event called ADMINPLUGIN_ACCESS_CHECK which would allow plugins to
overwrite it. This way it could be possible to give certain user groups
access to certain admin plugins without giving them admin or manager
permissions.

Note: this does not change how the "Admin" link is shown, it still
depends on ismanager or isadmin. A plugin as mentioned above would need
to influence the display via the MENU_ITEMS_ASSEMBLY event.

Note: this only covers the basic access check. Admin plugins may need
further adjustments for access to other parts of the plugin (like AJAX
components). An additional commit will update this for the bundled
plugins.

While refactoring into inc/Action/Locked, the fall-through call
to html_edit was missed.
See 952acff9

This removed the edit box from the locked page, which is needed
for users to get the page source or by etherpad lite plugin.

This change re-adds the call to html_edit for the locked action.

Signed-off-by: Michael Braun <michael-dev@fami-braun.de>

and actually use it in the edit form.

As discussed in #1933

shorter names are more in line with what we already use, makes less
layout problems in the documentation and is easier to type when telling
people about it.

They are now named min and max respectively, which is hopefully less
cryptic.

Pressing enter in the small quick-search-box while it was empty resulted
in a search for the current pageid.

This way they can be cleanly influenced by the plugins instead of having
to modify global state.

That parameter was introduced in cbcc2fa5 and removed in d22b78c8

This way we do not loose the context of the current page. Further, the
new id generated from the query before wasn't really that useful (see
issue #1124 ). And we can still generate a meaningful link "create a
page for your query", if that is considered useful.

Further redirects exist for the old urls, so bookmarked searches etc.
should mostly keep working.

This adds two new config options:

`search_limit_to_first_ns`:
Limit the search to the current X namespaces. When a search is executed
from a page within a deeper namespace, the first X namespaces will be
added as filter.
Possible use case could be with language namespaces to ensure that the
default search is initially within the current language.

`search_default_fragment_behaviour`:
Option to specify the default fragment search behavior

This commit should be without functional changes.

during testing, redirects may not be executed, ActionAbort can default
to redirecting which ould create an infinite loop.

This was the last remaining function in inc/action.php that could be
moved to the actions.

We now have quite the elegant cascade in the action handling.

uses the explicit redirect abort on success

Action can now abort to 'redirect' to explicitly trigger a redirect
back to showing the current page. Automatic triggering for post->show is
now only done when a 'show' action was not explicitly requested.

This also removes duplicated code from ajax.php

loadAction() and checkAction() are now public and could be used within
actionOK(). However some weird circular references prevent that. In
addition, actionOK is also used to check for things that aren't Actions
(yet) like 'rss' and 'top'.

also fixes the tests

Now underscores can be used to have sub actions. The loader will try to
find an exact match first, then begin removing parts from the end until
a matching action is found.

This is not how integration of plugins would ideally be done in this new
system. Ideally an action plugin would actually implement an instance of
AbstractAction and would just fall into the normal flow of actions here.

However to not break a gazillion of existing plugins, this is just add
the existing two events into the new system through the use of a Plugin
action.

Maybe we could add "new" action plugins later.