fix: Releasing GIL before attempts to lock the mutex

[v-ein]

---

name: Pull Request
about: Create a pull request to help us improve
title: Releasing GIL before attempts to lock the mutex
assignees: ''

---

Closes #2053
Closes #2077
Closes #2167
Closes #2366
(yes, all of them; they need to be mentioned separately in order to get closed)

Description:
This PR replaces most lock_guard calls (the ones that are under GIL) with a custom GIL-safe lock guard: to safely lock GContext->mutex without the risk of a deadlock, one needs to make sure that the code locking the mutex does not own GIL. This way in the mutex-GIL pair the mutex will always be locked first, GIL second - the rule of thumb in avoiding deadlocks is to lock mutexes in the same order everywhere. If we lock GIL first and DPG mutex second, we can't guarantee the order because Python manages GIL on its own and can easily lead to locking them in the opposite order.

The PR also fixes some race conditions and overall improves synchronization and stability.

If one needs to get back to old locking mechanism for some reason, DPG provides a build option named MV_NO_USER_THREADS - it was useful during development but I doubt that anyone will really need it (and it's only more or less safe when none of user threads, i.e. threading.Thread, call DPG functions).

Concerning Areas:
None.

[v-ein]

Please hold on with this one, I think I've found an issue. Not sure yet if it's related to this PR or not, will get back once I sort it out.

[v-ein]

Nevermind, I just forgot to remove MV_NO_USER_THREADS from my build config 😅. The PR is good to go!