Added user-defined context variable guard

[BrodyHiggerson]

Fitting with the "don't pay for what you don't use" concept, I wanted to have an optional way of injecting some kind of lock/guard around context variables in the registry.

I let the user define how the lock is created since, for me, I use a fiber mutex rather than std::mutex, so I need to be able to define it myself. I'm using the lock in the 'leaf nodes' of the function calls since I can't support recursive mutexes and the end result is the same.

Addresses #799

(Let me know if you want a PR against another branch; maybe main?)

[skypjack]

Unfortunately, this PR is no longer valid (if we consider branch wip as it ought to be, that is about to be merged with master).
Briefly, I've introduced a registry_context object here to address #575 (that makes perfectly sense to me). All functions from the registry have been moved to this object. These are the only functions available in the registry now.

I've no problem merging or reproducing the intent of this PR on a branch, adapting it and then porting it to master. There is no need for you to intervene. However, I wanted to ask you what your plans are to avoid conflicts. 🙂

[skypjack]

Actually, another option could be to turn the context type in a template parameter.
This way users can inject their own guarded maps or whatever or even suppress it. 🤔

[BrodyHiggerson]

@skypjack I actually had to comment out the

#ifndef ENTT_REGISTRY_CONTEXT_GUARD
	#define ENTT_REGISTRY_CONTEXT_GUARD()
#endif

section as include ordering was messing with it - some files/libraries would get to config via various utilities and I was struggling to always keep my own header/define before it. I think there's probably a better solution on the cards, but I'd definitely like some way to inject a custom lock either way. A template param could be nice - means the user can typedef entt::registry and use it in their code without worrying about include order shenanigans. I would just be worried about for example having that type replace the entire map and machinery and force the user to re-implement it - I want exactly what the context vars do, just with a lil' interception ;)