Stats module enhancements

We have implemented a set of ns-3 statistics module enhancements, which we are widely using in the statistics collection of the satellite module of SNS3 (http://satellite-ns3.com/). 

The statistics module enhancements can be summarized as follows:

- Modified gnuplot-aggregator
- Moved application-packet-probe to stats from applications module
- A set of (example) helper classes for setting up the delay and throughput statistics
- A stats-helper-example illustrating the usage of the additions
- A test suite for distribution collectors
- Sphinx documentation (.rst files) has been updated related to the additions
- A set of new probes, collectors and aggragators listed below

New probes:
- bytes-probe
- application packet probe

New collectors
- collector-map
- distribution-collector
- interval-rate-collector
- scalar-collector
- unit-conversion-collector

New aggregators:
- multi-file-aggregator

Other
- traffic-time-tag
- stats-callback-definitions

[Tom Henderson, 2016-12-09 05:53:34]

Sorry for the delay in reviewing.  It is a large patch and I am still thinking
about parts of it.

In general, the patch assumes that stats module depends on network and
application modules, but we have in the past tried to avoid such dependency. 
That is why, for example, application-packet-probe.h is in applications module. 
I would rather locate these pieces with non-core dependencies back to other
modules.

I left some comments inline about BytesProbe.

There are many collectors, and we have gone too long without any in mainline, so
although I would like to review those carefully, I generally think it will be
good to start including into stats.

I haven't tried multi-file-aggregator but it is probably fine to add.

StatsHelper may be better off in network/utils or network/helper?  It is kind of
like a node-scoped helper (I might rename usage of 'identifier' term to
'scope').

I realize that SNS3 blocks on this merge or else we need to find other homes
(e.g. back in SNS3) for the code, so I will return to this with more comments
sometime soon.

https://codereview.appspot.com/318800043/diff/1/src/stats/model/bytes-probe.h
File src/stats/model/bytes-probe.h (right):

https://codereview.appspot.com/318800043/diff/1/src/stats/model/bytes-probe.h...
src/stats/model/bytes-probe.h:51: *   value, but BytesProbe is.
I agree that this is needed additional capability (to trace a
'TracedCallback<uint32_t>' as opposed to a 'TracedValue<uint32_t>').  However, I
question whether it needs to have 'Bytes' semantics rather than just the
underlying data type like all of the other probe types.

Ideally, it seems to me that something like:

template<typename T>
class TracedValueProbe<T> ...

and 

template<typenameT>
class TracedCallbackProbe<T>

would be the best for this.  I do not remember the reason we had difficulty with
templates when the probes were originally done.  So we have presently a
Uinteger32Probe (to hook to a TracedValue<uint32_t>) and this code is proposing
a Uinteger32TracedCallbackProbe (but calling it a BytesProbe).

So in short, I agree with the functionality but would like a different name, and
would like to check again if templates might work.