fixes #2330

Punctuation is more natural, makes sense with CSS switched off
and makes screenreaders add a little pause.

This implements some of the changes discussed in #2314:

1. last mod and number of hits are on the same line and always shown
2. There is a class around the last mod string so it can be
hidden/replaced by an icon
3. All items in the resultBody returned by the event are wrapped in
`<dd>` tags to ensure validity. They get their array key as class
4. There is still a wrapper div around each result for styling purposes

Recent changes to the search results page added various divs
to the pre-existing description list, which is invalid.
This fixes that by a) removing a couple of unnecessary elements
and b) interpret the 'last modified' line as another 'dd'.

This removes a lot of reudundant CSS classes in favor of cascading
selectors. Styling isn't done, yet this is just a first step.

Still to do:

* aria labels
* styling the toggle mechanism
* RTL styling
* making sure everything displays correct when no JS is available
* translations may be missing
* refactoring the rest of search.less to make use of LESS features

This functionality is inspired by what other large search engines are
doing.

This add some search assistance to simple, single-word search queries
which may be restricted to a single namespace.

Further improvements:
* better styling
* trigger events for other plugins
* set namespaces directly from fulltext search results
* some more config options

This also adds the default theme color for the DokuWiki template as the
green from the existing links.

This adds some simple defaults for the guaranteed placeholders. This
ensures plugins can safely use these placeholders even when a template
did not implement them.

This looks a bit better and is closer to the original, even though the
sizes are a bit weird now.

this got lost in a previous update

also dokuwiki and php are on https

This basically reimplements tpl_action_dropdown but makes use of the
other menus (by setting the context to mobile) and thus still triggers
the appropriate events. This makes #1598 obsolete.

tpl_action_dropdown (and the other tpl_action* methods) still need to be
replaced to make use of the new Menu system.

this adds an option to print the menu without icons (as we do in the
dokuwiki template) but icons were added nontheless

also adjusts styles and adds images

all menu items should have a default SVG. Template authors then can
decide if they want to use them or not.

These are only the page tool SVGs. More need to be added.

When an svg has a fill attribute directly on the path, we need more
specifity to override it.

I used svgo to strip all unneeded cruft from the svgs

Now any arbitrary attributes can be passed as 4th argument. This way
classes etc could be added by plugins.

This will open up the discussion from #236 again and I'm not sure how to
solve this best.

The TEMPLATE_PAGETOOLS_DISPLAY event is very specific to the dokuwiki
template in theory. In practice many other templates implemented not
only the same event but also use the same HTML (and often even the same
CSS). Which makes the event more like a core event.

This branch now changes the HTML the event expects back from handlers.
When merged it would immeadiately break all plugins implementing this
event (and by broken I mean the layout/design of the template breaks).

Since the expected data changes, I would argue this should be a new
event or at least be implemented in a way to not break the design by
installing an old plugin and by giving the plugin a chance to know if
it's running on the old or the new code.

This is what this commit does. By changing the view names, old plugins
should not display (because they hopefull do not handle those views) but
gives them an easy way to handle the old and new views in one plugin.

However, I'm not perfectly happy with it, yet.

The way I implemented the new SVG handling is by means of a new class
dokuwiki\template\dokuwiki\tpl which provides a pageToolAction() method.
Plugins could use this method to easily return the proper HTML for the
pagetool items and we could adjust this method later on to make
adjustments to the pagetools without breaking anything again.

However this method is template specific again. While it would possible
for plugins to use this method even when the wiki runs another plugin
emitting the event, it would be a bit weird.

A better way would be for the event to not expect HTML at all, but
instead a data structure of the data currently passed to
pageToolAction(). Templates could then decide to implement the event,
but still render the data in a completely different way...

OTOH this means plugins are no longer free to add whatever they want
into the pagetools. We once argued plugins might want to add submenus or
other fancy stuff there. But in fact no plugin ever did.

If we decide to go this new way of making the event more of a first
class citizen of template development, then we would probably have to
move parts or all of the tpl class back to the core.