app: Start adding custom properties

Load custom properties on start (we won't support live changes), and add
them to nodes upon new-node signals.

Currently there's one exec per property added, some "buffering" and other
improvments coming w/ the addition of a new task visibility & co.
task: Add visibility INTERNAL_LOOP

This visibility is used with a "pre-worker". The idea is that when calling
donna_app_run_task() it will if needed create a new thread and start a
new main loop in it, then attach an idle source that will pre-run the
task.

Then, the pre-worker could return TRUE to have the task run right away,
or it could e.g. attach a timeout source (that will run the task). This
allows e.g. to have a few tasks to "pile up" in the main loop, and then
have one script running for all tasks at once (this is all very custom
properties talk).
node: Fix possible multithread condition in node_refresh()

In the worker when refreshing properties, we connect to the "notify"
signal to keep track of which properties are refreshed. Although any
refresh from our called refresher will happen in this thread, there's
no guarantee that another thread won't refresh one of those properties
on the node at the same time.

So we need a mutex around refreshed to handle such cases.
node: Add refresher_task to handle visibility INTERNAL_LOOP

Alongside visibility & refresher, we now take a refresher_task that,
for INTERNAL_LOOP, can be called to return the corresponding task to
refresh the property.
treeview: Minor optimization

Or fix. refresh_cb() is a task callback, and as such always runs in the
thread UI, so there's no need for a mutex.

(We could connect to notify::state waiting for tasks to go POST_RUN, in
which case the signal handler would run in the task's thread, but there's
no point really in adding such extra complications.)
node: Add functions to get array of tasks to refresh properties

To take full advantages of VISIBILITY_LOOP on refreshers, it might be
good to get an array of tasks: the node's internal one (if needed, to
call refreshers directly), and those from refresher_task (i.e. w/ said
VISIBILITY_LOOP), so the node's internal task doesn't need to be there
for no reason, nor won't block waiting for other refreshers.
app: Finish adding custom properties, using INTERNAL_LOOP tasks

When a task LOOP is started (prerun), we simply add the node to an internal
array for refreshes of that property, waiting 800ms (or 20 items) to
trigger the task-process.

This is to limit the number of exec required, and speed things up a bit.
app: Reload arrangements on config changes

Or, main ones. For treeview-specific ones, we simply unload whatever was
cached (to be reloaded on next use, when it happens).
treeview: Minor fix

On node-new-child we shouldn't add the node on NONE, simply update the
expand state and add a fake node.
conf: Minor tweaks
treeview: save_to_config(): Fix not saving right column layout

Would save the layout from the current arrangement, instead of what's
currently in use/in memory.
app: custom props: Fix refresher not really being blocking

The only way the custom refresher should ever be called is for blocking
calls (e.g. donna_node_get() blockingly), and so it is meant to block.

Since we need to wait for the task-process, we need to do so blockingly
as well, instead of using donna_task_wait_for_it() which could start a
new main loop (to avoid blocking).

Example: go in folder w/ a custom property, and set a VF using said CP.
If not all rows were visible, and non-visible rows haven't had their CP
refreshed, the filter (via donna_filter_is_match()) would trigger the
blocking refresh call.

If we were to start a main loop during that time, the UI does not block,
but the main loop processes the notify signal, refilters the node, thus
making the pending refiltering (which called the filter) work on a now
free-d memory... and (likely) segfaults.
pattern: Handle NULL as string to match against

No string or empty string will never match, but this makes things easier.
treeview: NORMAL refresh now refreshes all needed properties

It used to refresh set properties (on all nodes/rows), like VISIBLE or
SIMPLE do. Instead it now asks to refresh all needed properties as
defined by all columns, which means e.g. all custom properties of non
visible rows will be refreshed as well.
app: custom props: Add option preload

Set it to true to trigger the refresh as soon as the property has been
added to the node. Else, it's only done when requested, e.g. because the
row is visible on list using/showing that property.
treeview: Don't refresh props for non-visible rows

When a ct gives a list of props to refresh in order to be able to render
the cell, we'll ignore non-visible rows.

This is because otherwise if there was e.g. 2 custom props (CP) on the
same nodes, 1 of them being preload, then the node-updated would trigger
a row-updated and have the treeview redraw the row, even when not visible.
And we would then trigger refreshes for the other CP, when that might not
be wanted.
app: custom prop: Add option "type" (cp-type)
app: custom properties: Support groups

With option is_group=true a CP one can define a group of CPs, all sharing
the same cmdline (and preload). Point is when the called process will
get all the info at once, no need to do multiple calls for no reason.
ct-perms: Fix get_props()

The analysis of the format string to determine which properties was
actually needed/used was bugged, e.g. not accounting for mode when showing
a colored use/group name.

But, get_props() should return all properties that might be used for render,
sorting or filtering. So it shouldn't be based on analyzing the format
string, the ctdata is to be used when the property is defined there.

(This will be even more important with custom properties and ON_DEMAND
property refreshing.)
treeview: Refresh column properties upon refresh ctdata

Because one of the option changes might have been which property is
used by the ct.