qom: add object_property_add_unnamed_child

This interface allows us to add a child property without specifying a
name. Instead, a unique name is created and passed back after adding
the property.
QSource: QEMU event source object

This references QContext, which will be introduced later (and also
references this). These will likely be squashed eventually, but we leave
them separate for now for easier review.

This implements a QOM-based event source object which is used in much
the same way as a GSource.
QContext: QEMU event loop context, abstract base class

This class provided interfaces and helper functions for an event loop
context modelled closely on GLib's GMainContext. It drives a number of
QSources, which are in turn modelled on GLib GSources, and driven in
very similar fashion (prepare/poll/check/dispatch interfaces). It also
provides a mechanism for creating a thread and driving itself.

QContexts are attached to the QOM composition tree via unique paths and
make use of that to provide global registration/query mechanisms.

QContexts implementations can be instantiated, referenced, and
run via the -object command-line parameter.
GlibQContext: a QContext wrapper around GMainContexts

This QContext implementation wraps a GMainContext and maps most
interfaces to the obvious/corresponding GMainContext interfaces.

It can be used as a near drop-in replacement for event loops based
directly around GMainContexts, and provides support for direct handling
of GSources (which is unique to GlibQContext, since GSources are opaque
outside of GLib)

This can be used as a stop-gap between GLib event loops and QContext
implementations that don't rely on GLib. Most GSources can be trivially
ported to QSources to decouple such event loops from GLib, though due to
the use of things like GIOChannels where we can't easily take this
approach, we'll likely have at least one GlibQContext event loop for the
forseeable future.
QContext: add unit tests
iohandler: associate with main event loop via a QSource

This introduces a GlibQContext wrapper around the main GMainContext
event loop, and associates iohandlers with it via a QSource (which
GlibQContext creates a GSource from so that it can be driven via
GLib. A subsequent patch will drive the GlibQContext directly)

We also add "QContext-aware" functionality to iohandler interfaces
so that they can be bound to other QContext event loops, and add
non-global set_fd_handler() interfaces to facilitate this. This is made
possible by simply searching a given QContext for a QSource by the name
of "iohandler" so that we can attach event handlers to the associated
IOHandlerState.
main-loop: drive main event loop via QContext

This series attaches the global AioContext's GSource to the QContext
we've layered on top of the main GMainContext. This, paired with the
similar treatment given to IOHandlers earlier, allows us to drive the
main loop without using fill/poll functions to add/dispatch events that
are external to our main (Glib)QContext.

This patch breaks Slirp, which needs to be re-worked so that it can be
driven via QContext. Patches are on the list to port that to GSource,
so we assume for the purposes of this RFC that that's a solved problem.
dataplane: use a QContext event loop in place of custom thread

virtio-blk dataplane currently creates/manages it's own thread to
offload work to a separate event loop.

This patch insteads allows us to specify a QContext-based event loop by
adding a "context" property for virtio-blk we can use like so:

  qemu ... \
    -object glib-qcontext,id=ctx0,threaded=yes
    -drive file=file.raw,id=drive0,aio=native,cache=none \
    -device virtio-blk,drive=drive0,scsi=off,x-data-plane=on,context=ctx0

virtio-blk dataplane then simply attachs/detaches it's AioContext to the
ctx0 event loop on start/stop.

This also makes available the option to drive a virtio-blk dataplane via
the default main loop:

  qemu ... \
    -drive file=file.raw,id=drive0,aio=native,cache=none \
    -device virtio-blk,drive=drive0,scsi=off,x-data-plane=on,context=main

This doesn't do much in and of itself, but helps to demonstrate how we
might model a general mechanism to offload device workloads to separate
threads.