Review concurrency to address static_mut_refs lint

[veeenu]

There is a new lint in nightly Clippy, static_mut_refs that is currently breaking our builds.

I wholeheartedly agree with it, I never liked having to have static mutables but unfortunately that seems to be a ubiquitous requirement for hudhook's use case.

So far, I haven't seen any reports to suggest that hudhook's clients willingly use more than one thread, and in the meantime I discovered that dear imgui itself is not thread safe.

For the time being, I will disable the lint to keep the project moving, but before long I want to evaluate different ways of managing the global state.

One possible avenue would be to move everything to Mutexes and just confine the imgui::Context into a static mut in pipeline.rs. This would add overhead in theory, though if everything keeps running from the same thread I don't see it being that impactful. Pipeline would then be the only entity responsible for passing &mut Context references around, so we can sort of stitch some form of ownership around it via other synchronization mechanisms.

Another possibility would be using thread locals but that would still require us to use mutable statics so it's not really a solution to our problem.

[veeenu]

• Idea: make Pipeline be some sort of a global singleton that's only ever visible within a single spawned thread. Unsafely loan a pointer to drawlists across threads, manually managing its lifetime (it only needs to stay alive for the duration of the draw operations).
• Idea: test whether we can ensure everything is running from the same thread and convey that constraint to the type system somehow.