gltrace: don't destroy GLMemoryShadow-s which are still in use

This fixes shared coherent buffers behavior
which causes a freeze in "Deus Ex: Mankind Divided".

Here is an example of the problem, for instance
we have two shared contexts `CA` and `CB` and we do something like:
1. Create buffer `BA` in `CB`
2. Map it in `CB`
3. Destroy `CB`
4. Use mapped `BA` memory  <<< This step will cause the freeze
                               because on the step `3.` we destroyed `CB`.

Destruction of the `CB` leads to `GLMemoryShadow` destruction which destroys
the memory allocated for the `BA` and then it leads to the freeze in
`PageGuardExceptionHandler` with SIGSEGV/SEGV_MAPERR becuase
the client is trying to use the memory received from opengl

Here is a spec OpenGL 4.6 "5.1 Object Deletion Behavior":
"... If a shared object
 is not explicitly deleted, then destruction of any individual context has no effect
 on that object unless it is the only remaining context in the share list. Once the
 last context on the share list is destroyed, all shared objects, and all other resources
 allocated for that context or share list, will be deleted and reclaimed by the imple-
 mentation as soon as possible."

So we shouldn't destroy resources shared
between several contexts until all of them are destroyed.

v2: fix Xcode compilation error

Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>