create publisher in separate process

To send data across the process boundary, a publisher/subscriber pair
needs to be created together with stub/skeleton wrappers for each
side.  This commit begins the work.

Current skeleton code creates a thread to service the socket, which is
a natural decision to make.  Unfortunately, QML (and other UI kits)
have limit UI interaction to the gui thread.  When the skeleton thread
attempts to post metric descriptions to a GUI element, an assertion is
thrown.

This needs to be sorted out in one of a couple ways:

 1) all input processing happens on the main thread.
    - this implies that a set of sockets needs to be checked with
      select() on a regular basis by the main thread.  Or, a thread
      blocks on the fd set, and posts an event to the main thread when
      any socket has data.

    - a limitation of this approach has to do with synchronous calls.
      remote synchronous calls are not really possible in this
      paradigm, because they would have to be limited to the gui
      thread, and would block the gui.

 2) all GUI events are posted to the GUI thread via a slot/signal.
    This allows more conventional RPC, but will result in a tedious
    layer between the GUI and the rest of the app.  This seems similar
    to the concept of a QObject View-model.
got remote publication working, with real data
fix UGLY proliferation of slot/signals around stub/skeleton implementations.

The rule that has to be followed is that you can't post an attribute
or send a signal to the GUI thread from anything but the main thread.
To get around this, I was trying to have the skeleton threads emit
signals that the subscriber/producer models could catch on the main
thread, where they were created.

It is simpler to just call through to those models off-thread, but in
a thread-safe way.  The implementation of the virtual methods
satisfied by the model can then translate to QObjects in the UI
thread.

This is accomplished by creating a slot/signal pair within the model
object, and connecting them when the object is constructed.
Model notification (publication etc) can be received in any thread,
but the model has to emit a signal to itself so that subsequent QML
attributes can be updated in the main thread.  The signal is handled
on the UI thread as per standard Qt.

This solution collapses the model-view (QObjects) and the
model (Grafips subscribers etc) into a single class.
Remove QObject from publisher/provider classes

publishers and providers will be instantiated within the
fips-instrumented application.  Since fips is not going to link
against Qt, we can have Qt in those classes.

The Qt types were necessary to get data flowing within a single
application.  With this change, the stubs became the QObjects, since
they are now instantiated in QML.
drop double-registration of provider
adjust connection window height for hdpi
begin splitting off the publisher side

The target application (as instrumented by fips) must produce metrics,
handle subscriptions, and send data.  However, fips cannot be expected
to have a dependency on Qt.  This commit begins a restructuring of the
files to split off the remote code and remove unnecessary dependencies
from it.