Avoid non-estimated frames

After #213 (closed), non-estimated frames are not going to be in the Trajectory nor notified to problem. However, Capture::move() is required for the cases in which a KF of a compatible time stamp arribed. This is dangerous and several things have to be checked and guaranteed. However, reviewing the current implementation of the processors, these frames are in fact not necessary. They are just used as a state holder.

• In ProcessorMotion and derived processors the last frame is holding the resulting state without being used or accessible. So wasting time storing.
• In most of ProcessorTrackers, are just mantaining a frame with the state asked to Problem but not used. In the derived processors that really need this state it could be asked directly.

I propose to just avoid (remove) the existence of "floating" frames. This would remove all the machinery for registration/unregistration, etc. Also, it would imply that Capture::move() can be definitely forbidden since processors will have floating Captures that will be linked to a (notified or created) new KF.

added To Do (release) label

mentioned in issue #213 (closed)

We'll have to think about a way to print state and time-stamp of processors in problem->print()

but printing is defined in the derived classes.. the alternative that is used in each case will be "printable"

I think we should focus on this issue. We are in a strange midterm that is confusing and avoids us to put more assertions and checks.

We can skip the decision about avoiding the non-key frames (state and stamp containers have other solutions). But we definitely should avoid link() and setProblem() for NON_ESTIMATED frames. Also, adding the assertions to TrajectoryBase::addFrame() and FactorBase constructors ensuring that frames are KEY.

Can we close this given that we are working (and finishing) #313 (closed)?

Closing this after #313 (closed)

closed