[SYCL][Graph] Potential race condition in CommandGraph functions in queue_impl.hpp

[mmichel11]

Initially discovered by @slawekptak. We have a potential race condition between several CommandGraph functions in queue_impl.hpp when accessing the MGraph weak pointer:

• The race condition is between getCommandGraph, hasCommandGraph, and setCommandGraph
• Only setCommandGraph takes the queue lock. The other two functions call lock or expired on the graph without acquiring the queue lock.
• Without acquiring the queue lock in getCommandGraph and hasCommandGraph, the MGraph pointer itself may be reassigned during this operation which is a data race. The synchronization must be improved here, or we need to demonstrate this scenario cannot occur with how these operations are used.

The wording from https://en.cppreference.com/w/cpp/memory/weak_ptr/atomic2 specifying this is a race condition:

If multiple threads of execution access the same std::weak_ptr object without synchronization and any of those accesses uses a non-const member function of weak_ptr then a data race will occur unless all such access is performed through an instance of [std::atomic](https://en.cppreference.com/w/cpp/atomic/atomic.html std::weak_ptr>.