analysis.lami: correctly handle Number (double, long etc.) type graphing

analysis.lami: correctly handle Number (double, long etc.) type graphing

LTTng analysis return mostly long values either for the time stamps or
actual measurements. SWTChart, on the other hand, deals only with
"double" numerical values. Casting long to double causes a loss of
precision for big long value (e.g time stamps).

E.g: Loss of precision occurs when time ranges with a big minimal value
(2^62) but with little delta (1 ns) between events exist. Graphs
generated from such time ranges as an axis would result in a single dot
which is a clear problem.

The presented solution uses linear mapping to preserve resolution and
precision when possible.

The linear mapping requires two ranges: the internal range and the
external range.

Each graph is responsible to provide an internal LamiGraphRange. This
range is the internal representation in double in which all raw
(external) value are to be mapped. For now the default internal range is
0 to 1.

The external range [raw values range] is generated by finding the
minimal value and maximal values of aspects to be plotted.

Each point is then mapped to a corresponding value from the internal
range:

eV = external value
eR = external range
iV = internal value
iR = internal range

iV = (( eV - eR.minimum ) * ( iR.delta / eR.delta )) + iR.minimum

Since the default internal range is from 0 to 1 all raw values are
mapped to a value from 0 to 1.

On graph tick generation axis formatter transforms internal
representation to external representation and formats the result.

Other change:
- Aspects now return their numerical values via resolveNumber to ensure
  no casting is done.
- Move axis formatter to ui plugin.

Bug: 493941

Change-Id: I289180e10a7f1cbf6ecdd1beba93549b8fbe4c23
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Alexandre Montplaisir <alexmonthy@efficios.com>
Reviewed-on: https://git.eclipse.org/r/73239
Reviewed-by: Patrick Tasse <patrick.tasse@gmail.com>
Tested-by: Patrick Tasse <patrick.tasse@gmail.com>
Reviewed-by: Hudson CI