Fixes #395.

See also b10b2a71 (PR #1840)

Closes #1868

Fix horizontal and page scroll on GTK3

In addition, the signal allows plugins swallow the event so it's not
processed by Geany.

Small typo (grammar)

Before, **boldface** or *italics* (also _italics_) would not generally show as that, definitely not with the default color scheme. After this change, they appear with the same color as normal text but with that typography, in all color schemes.

Use HTTPS URL for domain www.geany.org

Our custom scroll handler for horizontal (Shift+Scroll) and page
(Alt+Scroll) scroll didn't properly check the scroll direction and
assume that if it's not down it's up.  This was mostly not a problem
because the other types only were left and right scroll events, which
are a lot less common.

However, it became a lot more problematic with GTK 3.4 that introduced
"smooth scrolling", and thus a new scroll type that can happen for
events in any direction.  We then would scroll up (as we assume "not
down" is up) regardless of the actual direction of the event.

It's still not clear why we'd get smooth scroll events on X11 as no
code I can find asks for it and we generally don't get those, but
sometimes a Scintilla widget starts receiving them, leading to the bug.
On Wayland on the other hand, Scintilla asks for smooth scroll events,
so we need to have a fix for it in any case.

Replace all occurrences with the command below.

    git grep -l 'http://www.geany.org' | xargs sed -i 's,http://www.geany.org,https://www.geany.org,g'

Add GI-compatible msgwin_*_add()

Closes #1748.

Make the brief text be distinct between msgwin_*_add and msgwin_*_add_string().
Also add @see directives where appropriate. Lastly, add @since to
msgwin_status_add() for completeness.

The variadic variants cannot be gobject-introspected, i.e. are not available
in  Peasy.

In fact, msgwin_compiler_add_string() and msgwin_msg_add_string() already
existed and have just been exported. msgwin_status_add_string() is new but
msgwin_status_add() becaume a wrapper around it in the same fashion as the
other two pairs.

Fix PM button desynchronization and possible crash

This prevents loading a spurious tag for the format specifier line, as
well as fixing loading of CTags format with a format specifier line.

Before this change, the file pointer was rewound after reading a format
specifier line; but this had various unwanted side effects depending on
the recognized format:

* For TagManager and Pipe formats, it led to loading a tag named after
  the format specifier (e.g. a literal "# format=tagmanager").  This
  was fairly harmless and only introduced a spurious tag seldom even
  used because "#" isn't usually considered for looking up completions.
* For CTags format, having an explicit specifier led to failure to load
  the file in most cases because the specifier line would be parsed but
  doesn't usually follow the format's requirements, leading to early
  abortion loading that file.  On some very specific specifier lines
  actually following CTags format, it could have led to loading a
  spurious tag instead.

Fixes #1814 and closes #1816.

On "Save As..." a text in the form 'untitled.ext' will be replaced with the chosen
filename if it is found in the first 3 lines of the document. This PR adds a description
of the feature to the manual. Fixes #753.

Fixes #779.

When toggling a plugin, we temporarily set the tree store's row entry
for the plugin pointer to NULL as we destroy and reload the selected
plugin, and its pointer would be invalid in the meantime.  This results
in the filter we use to display search results to temporarily hide the
row, changing the actual number of rows and thus, depending on timing,
this will or will not change the selected row (it will when double
clicking, not when single-clicking), in a seemingly more or less random
fashion as we use a sorted model.

Finally, as we manually update the buttons visibility for the toggled
plugin (as we otherwise do only for changing selection, which should
not happen in this case -- well, most of the time as you can see), this
can lead to the buttons to be updated for a now unselected row, getting
those out of sync.

The fix here is not to actually hide rows with a NULL plugin, because
it can only happen in 2 cases, where we actually want to see it:

1. while toggling a plugin, as explained above, in which case it had to
   match the search already.
2. when there is no plugins and we want to display a "No plugins
   available" message, and the search should not affect this.

This incidentally also fix the "No plugins available" so it's actually
visible, instead of always hidden.

Fixes #1781.

This should not be needed in normal operation, but is safer if the UI
gets out of sync for some reason.

Handle continuous G_IO_IN-s without any data.

This fixes spawn clients using recursive sources, like the Scope
plugin.

Part of #1789

Should there not only be one space here?

Say hello to Geany 1.34 "Keong"!