Fix for issue #108: only if both parts of traj relay are running is 'motion possible'

This updates the conditions that need to be `true` before the *motion possible* field of the `robot_status` message is set to `true`: runtime status of the `ros` and `ros_relay` programs is now taken into account.

This should not introduce any incompatibilities.

Tested both in simulation and on a real R-30iA, HandlingTool, V7.70.

> This might be a style thing, but I like the logic captured in nested IF statements, that way it's clear what logical statements evaluated.

I guess this might be something that also depends on what you are used to doing: personally I don't really like multiple nested conditionals. *Early out*, *fail fast* or using [*guard clauses*](http://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html) has my preference: very easy to read and no indefinite nesting of `IF` in `IF` in `IF` in `IF` (and then climbing out at the other end with `ENDIF`, `ENDIF`, `ENDIF`, etc, with no clues other than indentation as to which branch this `ENDIF` is terminating).

I've heard it being referred to as *ladder programming* (not to be confused with what is used on PLCs): to understand the most inner bodies you have to climb down (or up) a number of conditional branches, while trying to remember the intermediate results of your mental evaluation of the conditions you already passed.

> In addition, the *safe* value (`false` in this case) should be set by default and only unset (`true` in this case) if the conditions are correct.

I think the *safe* value is actually set twice? Once in `irs_reset(this)`, called at the beginning of `irs_update(..)` ,and once again on line 274 (in the proposed version of `libind_rs.kl`), just before the `IF(mot_psble_(..)) ..` line: 
```pascal
this.mtn_psble_ = TS_UNKNOWN
IF (mot_poss_(this, sstat__)) THEN ..
```

Also, I was under the impression that the safe value for a `TriState` was *unknown*? From the [State Feedback](http://wiki.ros.org/Industrial/Industrial_Robot_Driver_Spec#Industrial.2BAC8-Industrial_Robot_Driver_Spec.2BAC8-groovy-2.State_Feedback) subsection of the *Industrial Robot Driver Spec* page:

> * robot_status (industrial_msgs/RobotStatus)
>   * [..]
>     *  status values should be set to -1 if not yet available/implemented 

I've understood that to also include: *or cannot be determined*.

> The reasoning is that the setting of the variable only happens in two places (this would make it easier to track down problems). For example, I nearly missed that this.mtn_psble_ is initially set in logic above.

I see your point about readability. I think I'll refactor the condition to not include the inversion, that will probably make it much easier to follow (less brackets).