introducing AbstractProcessor::updateProperties(DataContainer&) which is automatically called by AbstractPipeline when a processor invalidates its INVALID_PROPERTIES flag

Further work on Issue #141: Introducing TrackballNavigationEventListener::reinitializeCamera() with tgt::Bounds or the new IHasWorldBounds interface as argument

work in Issue #141: Implemented listening to viewport size property in TrackballNavigationEventListener and thus removed obsolete TrackballNavigationEventListener::SetViewportSize().

Instead of having the LQ mode tied to the pipeline, each VisualizationProcessor has now a lqMode property effectively halfsampling the viewport size. The TrackballNavigationEventHandler was adapted to these changes and thus simplified.

Even though many float-based properties derived from
FloatingPointProperty used the same step value, T(0.01), it had to be
specified when instantiating them. To reduce boilerplate code in
property constructors, FloatingPointProperty now uses T(0.01) as the
default step value.

Even though all integer-based properties derived from NumericProperty
used the same step value, T(1), it had to be specified when
instantiating them. To reduce boilerplate code in property
constructors, NumericProperty now uses T(1) as the default step value.

Numeric properties were previously incremented and decremented by 1 cast
to the property's underlying type, e.g. tgt::vec2(1). That worked fine
for integer-based properties, but those storing floating-point numbers
could benefit from using the step value in decrement() and increment().
Now that's exactly how NumericProperty behaves.

work on #135: changed VisualizationProcessor::_renderTargetSize to pointer and introducing VisualizationProcessor::setViewportSizeProperty()

Revised event handling system: Got rid of campvis::AbstractEventHandler and replaced with functionality of tgt::EventListener and tgt::EventHandler

FloatPropertyWidget and VecPropertyWidget configure their adjusters to
display as many decimals as their properties have significant decimal
places. Moreover, they connect to the s_decimalsChanged signal in order
to reconfigure their adjusters when the number of significant decimal
places of their properties changes.

Floating point properties were previously typedef'd to specific
instantiations of NumericProperty. Now that we have
FloatingPointProperty, which extends NumericProperty to control how many
decimal places should be shown when displaying the property's value, all
typedefs for floating point properties have been updated to point to it
instead.

As a result, many processors and pipelines needed to have their includes
and/or constructors fixed to import and work with the new typedefs.

FloatingPointProperty extends NumericProperty to control how many
decimal places should be shown when displaying the property's value. For
that reason, it stores information about the number of significant
decimal places of each of its components.

A new attribute has been added to all numeric properties: step value. It
determines the value of a single increment/decrement that numeric
property widgets use when their associated properties are modified using
sliders or spin boxes (users are still able to type any valid property
value in text edits).

Numerous processors and pipelines had to be updated to work with the
changed NumericProperty interface. However, choosing a well-suited step
value for each property can make it easier for users to modify the
property — using one step value for all properties leads to cases where
it is either too small, causing users to go through property values
which don't cause any visible change, or too big, making it difficult to
quickly determine the right property value.

Previously, widgets for int and vector<int> properties used only spin
boxes to display and let users modify the values of their associated
property.

Now that we have IntAdjusterWidget, IntPropertyWidget and all
IVecPropertyWidgets have been updated to use it to make it possible to
change the values of their components with not only a spin box, but also
a slider.

IntAdjusterWidget displays and provides two ways of modifying integers:
a slider that can be used to quickly change numeric values, and a spin
box, which is better suited for precise adjustments.

IntAdjusterWidget is a simple extension of AbstractAdjusterWidget<int>.
It is designed to be used by IntPropertyWidget and widgets for vector
properties storing integers.

DoubleAdjusterWidget used to inherit directly from QWidget. Rebasing it
on top of AbstractAdjusterWidget<double>, however, greatly simplified
its implementation and provided it with several additional API methods
for free.

AbstractAdjusterWidget is intended to be a base class for widgets
combining a slider with a spin box. It abstracts common functionality of
such widgets, leaving only signal/slot support and behaviour tweaks to
be added in concrete adjuster classes.

AbstractAdjusterWidget is a template class that can be parametrised with
either double or int. Its API closely follows that of QSpinBox/QSlider.

Due to its language extensions, MSVC is more permissive than GCC with
respect to C++ code that doesn't fully comply with the language
standard. LogHighlighter relied on 2 such extensions: non-const rvalue
references, and closing nested template argument lists with '>>'
(instead of '> >'). Its code has now been fixed to conform to the
standard, and compiles fine with GCC 4.7 as a result.

AbstractPropertyWidget's onPropertyChanged slot is invoked from non-GUI
threads. Previously, it would call updateWidgetFromProperty directly,
which resulted in Qt widgets being accessed from non-GUI threads. This
in turn led to random crashes when properties were modified quickly and
repeatedly from the GUI.

Now we invoke updateWidgetFromProperty via a signal-slot connection with
an internal signal, s_propertyChanged. This makes Qt take care of
queueing slot accesses in the GUI thread for us.

Fixes #36

Previously, property widgets have always had their components displayed
horizontally next to a label with the property name. However, that made
widgets consisting of many components (e.g. widgets for vector
properties) hard to use because their components were squeezed together.

Now AbstractPropertyWidget takes one additional optional argument,
displayBoxed. If it's false, the widget is displayed as before. When
it's true, the widget is laid out vertically in a QGroupBox. For now
only widgets for vector properties set displayBoxed to true.

Previously, widgets for double-valued vector properties used only spin
boxes to display and let users modify the values of their associated
property.

Now that we have DoubleAdjusterWidget, vector property widgets have been
updated to use it to make it possible to change the values of their
components with not only a spin box, but also a slider.

Previously, FloatPropertyWidget used standard spin boxes and sliders to
display and let users modify the value of its associated property.
Consequently, it had to synchronise the states of those widgets on its
own.

Now that we have a separate widget that implements the two ways of
changing double values that FloatPropertyWidget provides, it makes sense
to simplify FloatPropertyWidget's code by making it use
DoubleAdjusterWidget internally.

DoubleAdjusterWidget displays and provides two ways of modifying
double-precision floating-point numbers: a slider that can be used to
quickly change numeric values, and a spin box, which is better suited
for precise adjustments.

DoubleAdjusterWidget is designed to be used by FloatPropertyWidget and
widgets for vector properties storing floats.

The sizeHint method has been overridden in PipelineTreeWidget to return
a sensible height for the wigdet, while still reusing QTreeView's
hardcoded width.

The main window makes use of that to limit PipelineTreeWidget's maximum
height and give any vertical space reclaimed in this way over to the
widget displaying pipeline properties.

Each FloatPropertyWidget now gives the user two ways of modifying its
underlying property's value: the slider can be used for quick changes,
the spin box — for precise adjustments.

QtThreadedCanvas used to ignore all repaint events send to it by Qt in
order to avoid problems with threading. As a result, however, it would
become blank when docked/undocked, and display garbage in those of its
regions that some other widgets have moved over.

To fix this, the API of TGT's Painter class had to be slightly modified
and now mirrors that of Canvas with regard to painting-related
operations. The paint method has been made protected; it's supposed to
implement the painting logic and shouldn't be called directly. A public
repaint method has been introduced to let canvases notify their
associated painters that they need to be redrawn. The default
implementation simply calls paint() immediately; threaded painters,
however, override it to schedule render jobs that run in separate
threads.

All existing threaded painters have been updated to reduce the
visibility of their paint methods and provide public repaint functions.
Consequently, QtThreadedCanvas can now properly handle repaint events by
delegating to its associated painter's repaint method.

To stop the widget that contains pipeline properties from constant
resizing and taking space away from other widgets, its contents were put
in a scroll area that only resizes horizontally, and scrolls vertically.

Things like date-stamps, time-stamps, categories, and log levels are now
highlighted in every log message. This should make the contents of the
log viewer easier to scan by indicating which information is important.

VisualizationPipelineWidget and PipelineMdiSubwindow have been extended
to report changes in their positions to VisualizationPipelineWrapper.
Based on the information the latter receives, it decides when to undock
MDI subwindows and dock floating pipeline widgets.

As a result, it's now possible to drag visualization pipeline widgets
back into the MDI area and turn them into MDI subwindows.

The way visualization pipelines are displayed has been considerably
reworked. A new class, VisualizationPipelineWrapper, is now responsible
for creating all necessary representations (VisualizationPipelineWidget,
PipelineMdiSubwindow) of a visualization pipeline and seamlessly
switching between them in response to the user's actions (window
dragging, key presses, etc). As a result, it's now possible to drag
visualization pipeline widgets out of the MDI area and turn them into
top-level floating windows.