More flexibility in the global lock

Is your feature request related to a problem? Please describe.
lt.ThreadWithInvocationID allows one Action to run code in a background thread, with the ability to cancel it using the existing cancellation mechanism. However, if the global lock is enabled, it's not possible to run an Action, because it won't be able to acquire the global lock (which is already in use by the original Action thread).

Describe the solution you'd like
I'd like the thread that currently holds the global lock to be able to somehow "share" (or bypass) the global lock with selected threads that it has started. Arguably, it could be as simple as lt.ThreadWithInvocationID(target=thing.action, share_global_lock=True).

This probably requires a fair bit of extra code in GlobalLock and will want careful testing. However, I think it can be done safely and sensibly.

Describe alternatives you've considered
I think the best current work-around would inspect the Action descriptor to get the un-wrapped Action function. In many cases, this would mean it doesn't try to acquire the global lock and will work OK. It is very likely to go wrong, though, and quite ugly.

An option to bypass the global lock feels much less safe to me than a mechanism to share the lock.

Additional context
This would be required to make the current version of "flying z stack" work with global lock enabled merge request.

Start by locating GlobalLock and ThreadWithInvocationID, then trace how the global lock is acquired by an Action and by threads it starts. Define and test a safe way for selected child threads to share the lock without allowing unrelated Actions to bypass it; the flying z stack merge request provides the usage context.