docs: improve a little the GtkSourceBuffer doc

Reorganize the order of the functions. The class description describes
the undo/redo and then the context classes, so apply the same order.
Syntax highlighting is more important and is thus at the beginning.
Marks and other functions are at the end.

The generated html doesn't display the subsections. GTK-Doc could
separate the different sections into blocks, and display the titles.
Updated gujarati translations
Updated Indonesian translation
Apply line style also to main window
Updated German translation
Updated Korean translation
Updated Norwegian bokmål translation.
StyleScheme: add a comment
Disable by default unit tests for remote files

The code is kept in case we want to test it. But by default it is
disabled. gvfs should have good unit tests too.

https://bugzilla.gnome.org/show_bug.cgi?id=736188
lang-reference: update <replace> tag documentation

"external" was probably renamed as "embedded-lang-hook".
docs: minor fixes
Updated Czech translation
Updated Russian translation
Test UndoManager performances

And the results are....

Old implementation based on a GPtrArray:
Undo/Redo 10000 actions: 0.486454 seconds.
Undo/Redo 100000 actions: 4.822937 seconds.

New implementation based on GQueues (see next commits):
Undo/Redo 10000 actions: 0.494246 seconds.
Undo/Redo 100000 actions: 4.903951 seconds.

So the difference is small, it's linear with the number of undo's, which
means that an undo or redo is a O(1) operation. It was not the case with
the older implementation based on GList, because GList was not used
correctly (g_list_nth() was called on each undo or redo, because the
location in the history was not stored with a GList node, but with a
gint index).
UndoManager: start a new implementation

The code was quite horrible, with functions that do the reverse of what
they say they do, like action_list_prepend() that does an append on the
GPtrArray. Or 'next_redo', which is an index that begins at the end (!)
of the array.

Group of actions should be modelled into the data structure itself,
instead of having 'order_in_group', 'actions_in_current_group',
'num_of_groups', etc.

This new implementation will just try to make the code cleaner, with a
better data structure (a GQueue of GQueues). It won't add new features,
or make the Action more extensible (like a "search and replace" action
which would be different from a [delete/insert]). If one day GTK+ or GIO
has an Undo/Redo API, it will be the time to make the undo/redo more
powerful. And at that time, having a cleaner implementation will make
things easier to port the code to the new API.

A benchmark will be written to ensure that performances with the GQueues
are as good as with the GPtrArray.

See also:
https://wiki.gnome.org/Projects/GtkSourceView/UndoManagerRework
UndoManager: new implementation based on GQueues

See also the previous commit message.

Visible changes with the previous implementation:
- Word merging: before, the spaces _after_ a word were merged with the
word, now it is the spaces _before_ the word that are merged. See the
comment in action_insert_merge() for the reason.

- A group containing several actions will now never be merged with the
previous group. Before, the merging was done action by action.

- An insertion or deletion outside a begin/end user action is now
inserted into a new group for each action. With the previous
implementation, those actions were grouped into one undo/redo step.

- Different behavior for restoring the cursor position. The selection is
no longer restored. The cursor position is placed at the end of the
first action in the group. If the group contains only one action, it
simply goes to the end of the insertion or deletion. For a search and
replace, it always goes to the end of the first replaced occurrence.
If restoring the selection is desirable, the code contains #if 0
sections for storing the selection only if the selection is related to
the action. That is, for a deletion the selection bounds should have the
same offsets as the deleted text, otherwise the selection is not stored.