Ensure thread safety for calls

[mzabaluev]

GObject-based objects are not generally thread-safe, so it may not be safe to call GObject methods directly from different concurrent tasks. If we freely allow cloning and sending wrapped GObject references in safe Rust code, we should forward all GObject calls through a dedicated long-running task. grust::init could be the place where this task is started.

[mzabaluev]

Accordingly to a mailing list thread, we need to wait for #[non_owned] attribute (see the Rust issue) to be implemented in order to make our object wrappers non-sendable. Meanwhile, all calls to GObject should be issued from a grand central task.

[mzabaluev]

Gio async I/O, among others, relies on a GMainLoop running and calls callbacks in the thread of the caller's GMainContext.

I see two ways to implement it:

A. Create an ever-running global Rust task to run the GMainLoop and perform GObject calls for other tasks. This requires some things to be figured out, such as how to create globally accessible non-static things in Rust and not see support for this feature disappear in a couple of months :)

B. Write a support library in C (sigh) that will start a global GThread and run a main loop there. Method calls, return values, and callbacks will be shunted between the caller threads and the main loop thread by helper C functions.

Later on, we could explore tighter integration between the two event loops (see #4 for blocking Rust issues and follow-up discussion).

[mzabaluev]

In first approximation, implemented as of 9a15aad.
The eventual approach introduces the support library in C, as we need to work closely with GMainContext and run sentinel tasks in an utility thread pool.