solve issues on front methods on locking queues

[danielfaleirosantos]

The front() methods on locking queues (i.e. queue_spsc_isr, queue_spsc_locked, queue_lockable and queue_mpmc_mutex) have two issues that have been identified:

• The methods should return by value to prevent race conditions (i.e. when returning by reference, accessing the memory space can cause a race condition if some other access modifier is happening).
• the locking queues should lock through a mutex and etl::lock_guard(mutex). This was done (and then reverted) in commit 0f11716, but I think some extra investigation needs to be done as I think it was not optimized.

[mike919192]

I'll repost the example I gave in the linked PR, where there is a valid use for getting a reference to the data using front() with the SPSC queue variants

//consumer side of a SPSC queue
//producer is another concurrent thread
if (!queue.empty()) {
    {
        //get a reference to data that goes out of scope before pop is called
        const some_value_t & ref_from_queue = queue.front();

        //the reference is valid until pop is called
        do_something_with_ref(ref_from_queue);
    }
    //reference goes out of scope, pop it off the queue
    queue.pop();
}

The advantage of this would be avoiding a copy on the read side, which could matter if the queue were holding a struct. This is valid with SPSC queues and I've done validations with thread sanitizers with various implementations over the years.

I think where the concern is coming from is the MPMC queue. I think in that case it makes sense to force getting by value.