GitLab

Our templates have moved away from this, and we can remove it from our
sources too.

This is needed so that we can apply version macros correctly
in the future.

This converts the rest of plugin files that are not using DzlTaskCache to
IdeTask. Those modules will have to be converted on a per-function basis.

Not everything has to be moved to GTask, but most things should so that we
know exactly what is going on thread usage wise.

This also fixes an issue where we weren't returning a result for a task.

This does not need to be copied for intern'ing, as it will already be in
the data section. We can just use the raw string pointer.

This ports the module using run_in_thread to IdeTask so that we have more
control over what thread data could be finalized in.

This doesn't yet port the service to IdeTask, as that is more complex due
to using DzlTaskCache.

This moves blocking portions of shell discovery out of the UI thread by
setting a sensible default and asynchronously querying the host system
during application startup.

Fixes #439

This allows porting various code from gtask

The git stuff interacts with UI quite a bit, so its somewhat
important to ensure we are more careful about where we finalize
task data.

The service still needs DzlTaskCache, but we can use IdeTask
for lots of other stuff that will interact with widgets/etc.

This ports a number of the modules that are using run_in_thread
to using IdeTask so that we can control where finalize of
various associated data happens.

We want to ensure these finalize on the main thread, so use
IdeTask which can guarantee that.

This is another one of those where we want to be sure we're
free'ing things from the main thread.

This wasn't exactly able to handle all situations, so we removed
our use of it in Builder (which is better anyway). So now remove
this so we don't accidentally start relying on it in the future.

This ports the rest of the code-index to using IdeTask. The goal behind
this change (and many more upcoming) is to have more control over where
data is finalized.

We have more control over where things are freed using IdeTask,
and we can use this object as a way to catch any issues that
might still exist before we push things through the rest of the
code base.

That said, I've used IdeTask to catch lots of bugs already, so
I'm pretty confident in it's usage now.