task: Remove VSIBILITY_LOOP; Add pre-worker support

Instead of having a dedicated visibility which required a dedicated
thread/main loop and was mostly hackish (in that task workers were
reduced to close to no-op as the actual work had to be done before/in
other tasks, else it'd block the dedicated main loop), now every task
can have a pre-worker set.

When that happens, the task shall be prerun first, so the preworker can
do its work, maybe installing sources in the main loop to get there, then
set the task preran and trigger its actual start, which will then happen
as regular, so in a dedicated/UI thread as per its visibility.

Custom properties still "hack" this since the refreshing tasks are just
waiting (via sources from preworker) for the task-process to run, due to
the whole buffering/groupping that happens there.

But, it will be useful for all commands, so the parsing of argument can
be done via preworker, leaving the worker be only the actual command.
It's better/more obvious, and also removes any need for recursive main
loops started for "subcommands" when parsing arguments and possible
issues related to this.
command: Use pre-worker to parse arguments

Instead of having to resort to (recursive) main loops to handle running
subcommands as arguments, which was bas design, parsing arguments is now
done in the task's pre-worker.

If there's a subcommand to run, the corresponding task is created and a
source added to the main loop, to resume parsing. Once ready, the actual
command is started, leaving the worker only be the actual function of the
command, and nothing else.
command: Fix possible memory leak

Only if the task failed to be started, but still.
mark: Minor optimization

When creating a new node inside domain mark, it can only be in the only
container: mark:/

So we do have the corresponding node, parent, no need to look for it.
app: filter_nodes: Fix empty array is not an error

Should we be asked to filter an empty array, nothing is to be done but
that's not an error.
Add provider filter to handle filters

Filters are now handles via a provider, which means they aren't used as
strings but nodes via commands. (Behind the scenes, the same DonnaFilter
objects are used.)

The main benefit from this, besides making it more in line with how donna
works, is that now filters can be defined in config, to assign a name,
alias and/or icon name. So when filters are presented in a menu, they can
have a name (e.g. "From yesterday") and icon. It is also possible to simply
use the alias to reference the filter.

Specifically, nodes in filter will always have for location the filter
string, but one can get the node by using either said filter string (e.g.
"filter:size>100M") or the alias, prexifed by a pipe (e.g. "filter:|large")

This applies not only in commands, but also in other part of the config
where filters are used, e.g. color filters or custom properties. There,
a filter string can be used, or simply an alias prefixed with a pipe (i.e.
a valid location in filter).

Because now nodes are used when it comes to filter, a special node with
an empty string as location ("filter:") is used to mean "no filter".
Point is, when using e.g. tv_get_visual_filter() a node needs to be
returned, so when no filter is set this node will be returned. (It could
also be used to unset any VF, though the argument remains optional and can
simply be omitted still.)

Because it is a node in "filter" one can still assign a name, alias and/or
icon to it, as for any filter.
command: Add get_node_from()

Separate the domain and the location, so the domain can be fixed while
the location is the result of another command, e.g. ask_text()
conf: key 'F' is now a direct to edit current VF

Makes more sense/seems more useful than edit & apply a filter.
app: Fix possible segfault on app close

If a pattern was "leaked" and unref-ed after app_free() was called, we
don't have our hashmap anymore (when toggle_ref still gets called).

A better fix might be to remove the toggle ref on the patterns, but this
isn't (yet) supported.
gen-command-docs: Couple minor fixes

Most notably, if a command started with "@foo" and contained a colon
somewhere after, it was counted as an argument.
command: Add node_set_property()

Can set property that are string, int, uint or date. This is pretty basic
since you need to know beforehand the property's type and there's no
things like "now" or "an hour ago" and the likes, but that can be done
via a treeview's column (e.g. tv_column_set_value())
app: Fix comment about why the need of a rec_mutex

We don't handle filters, but still need a recursive mutex for ct-datas.
app: Minor tweak

No need to take the lock on toggle_ref for a pattern when adding a new
ref, since we don't do anything in that case.
app: Implement our own lock to separate things

Instead of one RWLock for visuals & providers and a (recursive) mutex for
everything else, we now use our own locking mechanism (mutex+cond+flags)
so we can separate everything (as if everything had its own lock) and
still use RW for visuals & providers (though, again, separatedly).

Much better overall and helps prevent situations where the lock is taken
for one reason and then blocking (possibly deadlocking) for another
reason.

One special case: when having a lock on col_ct_datas and triggering a
refresh_ct() then option_cb() can be triggered, thus causing a deadlock.
We handle this by failing to take the lock (instead of blocking for it)
and using an idle source to process the option_cb later (once the lock
is available).
provider-command: Add prefix '<' to make container

Prefixing a command's name/location with '<' will result in the node being
a container and not an item. The command is then triggered whenever
the node/container's children are accessed.

Obviously, only for commands returning a(n array of) node(s)
contextmenu: Minor tweak
contextmenu: Add TYPE_COMBINED for trigger+container

A new context-type "combined" allows to define a user item with the
usual option "trigger" for the trigger part, but also option "container"
for the container part.

This is obviously intended to be used w/ option "submenus" set to "combine"
since the resulting node will be a container that can also be triggered.

This allows to define the trigger (and other props, e.g. name, icon...)
as usual, all the while also defining the submenu's content (other than
by making use of the <...> syntax for other items).
conf: Use new type "combined" for selection filters

Note that because of current limitations, the left_click for menus of
filters refers to ":active" as treeview, since it's not aware of any
context at this point.

Later on, it'll be possible to use "@context_get_source_name (%c)"
instead of get the treeview's name from the context.
command: Add node_get_children()
command: Add nodes_add()