version bump
Merge pull request #29 from fqqb/algorithms

Algorithms
Update EV and PV screenshots for Yamcs user manual
Don't try to process string-encoded int as int
Use tmProcessor only if nobody else can provide the value

With the upcoming commit of algorithms, there is no longer anything
that distinguishes an output parameter from any other parameter.

So rather than having the TmProcessor verify whether there’s
an output parameter or not, just ask the TmProcessor last.
XTCE: Separate calibration logic from the extracting

This commit accomplishes a bunch of different stuff:
 - The calibration step was put in a separate class without
    requiring a ProcessingContext. The advantage being
    that it could be used elsewhere. This may need to
    be tweaked a bit further on though, because according
    to XTCE, calibrators could be context-specific as well.
 -  Raw strings are now really Strings, and not byte-arrays
 -  Type safety in algorithms is improved by relying on the
    XTCE parameter definition
 -  As a result, there are no more problems with parameter-
    values changing from one type to another (problematic
    in combination with the Janino-generated classes)
Make bitsize optional for (most) output parameters of algorithms

Outputs of algorithms don’t really need raw bit sizes. This commit
makes it optional (it’s still allowed, which could be exceptionally
useful).

In case a calibration is shared with another parameter, the bitsize
should still be specified to be the same as that other parameter.

There will now be an error message if this is not the case.

In the future it would be helpful if there is an exception to this for
output parameters, but that’s a bit of a hassle right now.
Verify correct processing of python algorithms for float&int
Fix support for longs and doubles

During calibration an integer value would only be interpreted
as long if its raw value is >= 32. That’s a wrong assumption:

1) StringDataEncodings also depend on the bitSize column. But
    this value has nothing to do with the bitsize of the engineering
    value.
2) Calibrations could increase the magnitude of numbers

Actually there was no way to have a java double engineering value even though the logic is all there.
Add support for booleans in spreadsheetloader

Booleans are sort of included in XTCE (as eng type), but not as
raw type. This commit adds support for both eng and raw.
The raw support is needed for when algorithms output
boolean parameters (otherwise it would be unintuitive if the user
had to, say, encode an output parameter as type uint/boolean.
Now he can do just boolean/boolean.

For regular parameters, any other raw parameter type is
also supported. Basically, anything that differs from zero
is considered true.

Empty strings, all-zero binary, integer 0, float 0, they are all false.