guard spsc queue push with mutex since it's not thread safe

[SzabolcsGergely]

SPSC (single producer-single consumer) queue documentation about queue push function:
Requires: | only one thread is allowed to push data to the spsc_queue
We had multiple threads calling HostPipeline::onNewData once USB packet arrived, queue push wasn't protected, so the data got released in between multiple threads pushing into queue and main python thread (consumer) consuming the queue.

This issue can be reproduced easily on commit e754c2b
w/ options : ./depthai.py -s previewout left right metaout -v /dev/null
where each thread is spamming the queue -artificially- every 1 ms to reproduce the clash.
When the issue happens in the terminal it will be printed (most likely) : Invalid packet stream name!deallocated
but technically it's subject to undefined behavior due to corruption.

Protecting the queue in both consumer and producer defies the purpose of non locking queue, the purpose of this PR is not replacing the current queue implementation with a locking one, but to solve the current issue in the current context.

[themarpe]

In this case the second push isn't protected. Maybe rather lock the whole segment?

{
    std::unique_lock<std::mutex> guard(q_lock);
    if (!_data_queue_lf.push(host_data))
    {
        _data_queue_lf.pop();
        if (!_data_queue_lf.push(host_data))
        {
            std::cerr << "Data queue is full " << info.name << ":\n";
        }
    }
}

[SzabolcsGergely]

Thanks, I was sleepy, forget to remove the unlock for extra safety.

[Luxonis-Brandon]

Thanks, both!

[Luxonis-Brandon]

Looks great and works for me.