release 0.26.0
version change
fixed bug caused by the read only ByteBuffer
Expose Yamcs archive through a web api

A first go at a web api, it uses chunked transfer because we
don't want to store to a temp file just because of the
content-length. Chunks can be pretty small, they are aligned
with the incoming data from the ReplayServer.

Only parameters & packets are supported, and profiles are
supposed to be predefined in <cache-dir>/profiles/
Merge pull request #24 from fqqb/webapi

Expose Yamcs archive through a web api
Algorithms: Use custom object for output value bindings
Allow user algorithms to set optional updated flag
Merge pull request #41 from fqqb/algo-obj-out

User algorithms can signal when a value was not updated
Report alarm events automatically (w/o needing subscription)
Split alarm functionality between checking and reporting

Checking an alarm is always done by PRM, as part of the
TM processing chain.

Reporting an alarm is a yamcs service that is activated
only upon request (when part of the services list)
Allow alarm event generation based on value changes

Previously only alarm events would be generated when
the severity of an alarm changed. With this commit, the
functionality was extended to allow reporting all value
changes, regardless of severity. There doesn’t even
need to be any triggers defined for each severity.
Prepare algo engine scopes for concurrent execution

So far we could get away with just using one ScriptEngine, and
reusing it for all algorithms. However, scriptengines are not
guaranteed to be threadsafe, and sometimes unwanted effects
can happen (e.g. this is the case with the current algorithm name
which is set on the engine before any run.)

Furthermore the current code did not make variables declared
in a library global (as in ‘shared’) for all algorithms. It now does
it correctly.
Set all algo inputs to null on initialize

This small change is just to prevent ugly undefined errors, so that
it can easily be checked whether a parameter was set or not
Support different trigger types for algorithms

Replaces the AutoActivate column with a new column trigger
A trigger can be either:
 - OnParameterUpdate(p1, p2, ...): an exhaustive list of parameter updates
   that trigger the algorithm.
 - OnPeriodicRate(fireRateInMs): An algorithm triggered at a fixed rate.

The default, if unspecified, is to trigger on all updates of any input parameter.
Merge pull request #42 from fqqb/alarm-and-algo

Alarm and algo