Adjust camera start/stop capture commands to lifetime of RS handle

[PeterBowman]

Capturing commands were subject to substate mode changes, whereas the lifetime of the RS object instance is tightly bound to the activity thread. This is not a problem in case the component is started in Neutral state and commanded to switch later to PushState as memory has been properly allocated at that time. However, doing so on component init (i.e. with <initialcomponentmode> parameter equal to PushState) causes the pipeline to attempt an early start. It fails since the thread is not created yet and, consequently, COMP->smart_rs_device is NULL. On each loop, fresh frames are requested from the device, but the RS framework complains about the pipeline not being properly started.

This commit defers initial pipeline start, decoupling it from state changes. Since COMP->smart_rs_device lives for as long as
the thread does its job, pipeline start and stop capture commands are now bound to thread start and stop, respectively. Also,
allocated dynamic memory is now properly destroyed on thread stop.

[PeterBowman]

As a side note, I was wondering if tryAcquire would be a better choice than acquire to avoid blocking the activity loop:

ComponentRepository/ComponentRealSenseV2Server/smartsoft/src/ImageTask.cc

Line 183 in 104e92c

statusCode = COMP->stateSlave->acquire("pushimage");