Don't destroy Python objects under the JIT compilation lock

Summary:
I ran the AI Labs test in D115743871 and got an error and the following stack trace (just relevant parts shown below):
```
9133 | Stack trace for 1 thread(s) [8782 cinderx_compile]:
9139 | PyEval_AcquireThread                        ← blocked waiting for the GIL
9140 | pybind11::gil_scoped_acquire()              ← explicitly asking for it
9142 | c10::TensorImpl::decref_pyobject()          ← must drop a Python ref
9145 | c10::TensorImpl::~TensorImpl()              ← a torch Tensor being freed
9153 | _PyObject_FreeInstanceAttributes
9159 | allocator_traits<pair<CompilationKey, ...Ref<PyFunctionObject>>>::destroy
9160 | cinderx::jit::Context::finalizeMultiThreadedCompile()   ← holds the mutex

9818 | Stack trace for 1 thread(s) [8772 icvr_launcher_m]:
9819 | __GI___lll_lock_wait                        ← blocked, untimed
9822 | pthread_mutex_lock
9824 | cinderx::jit::Context::funcDestroyed(...)   ← wants the mutex
9835 | Python stack trace for this thread (holds GIL)
9840 | torch/_inductor/compile_fx.py:773 _recursive_post_grad_passes
```

These logs are from the `watcher.cpp` tool, which prints all the stacktraces of all current threads when it sees that the GIL is being held for a while.
It seems that there's a deadlock with `funcDestroyed()` having the GIL and waiting on `JITCompilationLock` while `finalizeMultiThreadedCompile()` has `JITCompilationLock` and is waiting on the GIL in order to do deallocations.

The fix here makes it so that the deallocations in `finalizeMultiThreadedCompile()` happen outside the `JITCompilationLock`.

Reviewed By: DinoV

Differential Revision: D116940812

fbshipit-source-id: d9ed1c346a0b36e3cf32e960148a3685cb1a24ce

Author: Subbarao Garlapati

cinderx/Jit/context.cpp

@@ -482,27 +482,34 @@ void Context::addDeferredFinalization(
 }
 
 void Context::finalizeMultiThreadedCompile() {
-  JITCompilationLock lock;
-  fixupFunctionEntryCachePostMultiThreadedCompile();
-  watchPendingTypes();
-
-  for (auto& codes : completed_compiles_) {
-    makeCompiledFunction(
-        codes.second.second, codes.first, std::move(codes.second.first));
-  }
-  completed_compiles_.clear();
-
-  for (auto& [func, key] : deferred_finalizations_) {
-    // Re-resolve the compile rather than trusting a pointer cached while the
-    // GIL was released; the CompiledFunction may have been freed since, in
-    // which case it has already erased itself from compiled_codes_ and there
-    // is nothing left to attach the function to.
-    auto it = compiled_codes_.find(key);
-    if (it != compiled_codes_.end()) {
-      finalizeFunc(func, it->second);
+  // Destructed outside the lock: decref can block on the GIL, which deadlocks
+  // against funcDestroyed().
+  decltype(completed_compiles_) completed;
+  decltype(deferred_finalizations_) deferred;
+
+  {
+    JITCompilationLock lock;
+    fixupFunctionEntryCachePostMultiThreadedCompile();
+    watchPendingTypes();
+
+    for (auto& codes : completed_compiles_) {
+      makeCompiledFunction(
+          codes.second.second, codes.first, std::move(codes.second.first));
+    }
+    completed.swap(completed_compiles_);
+
+    for (auto& [func, key] : deferred_finalizations_) {
+      // Re-resolve the compile rather than trusting a pointer cached while the
+      // GIL was released; the CompiledFunction may have been freed since, in
+      // which case it has already erased itself from compiled_codes_ and there
+      // is nothing left to attach the function to.
+      auto it = compiled_codes_.find(key);
+      if (it != compiled_codes_.end()) {
+        finalizeFunc(func, it->second);
+      }
     }
+    deferred.swap(deferred_finalizations_);
   }
-  deferred_finalizations_.clear();
 }
 
 bool Context::finalizeFunc(