Uninitialized isMotion processors

Before changing the prior mechanism, all ProcessorMotion were installed and setOrigin() was called immediately. Now each processor is responsible of initializing itself, when the first capture is processed. Then it is possible to have a isMotion processor that is not initialized (setOrigin in case of ProcessorMotion).

For example, in some ProcessorMotion code, it is assumed that there is always origin and last but this is not always true anymore. getState(), getTimeStamp() or even getBuffer() functionalities are failing in this uninitialized case.

Also, all isMotion processors are called from Problem to get the state and time stamp. Maybe bool isMotion::ready() would be a useful method to allow Problem to directly avoid requesting things to the not initialized processors.

added Agreement required label

mentioned in issue #344 (closed)

@joanvallve are you on this one? Or should I take it? I think you are better placed than me in this one since you designed the prior / init algorithm. But I can do it if you are busy.

This is needed to complete #344 (closed).

Sorry I can't right now. #344 (closed) can be implemented without this feature, right?

Yes, #344 (closed) is actually finished and waiting for your approval for merging.

This feature can be implemented in the future independently of #344 (closed)