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.