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