Python bindings crash when matplotlib is also used

Polyscope's python bindings seem to interact strangely when matplotlib is also used. Here's a simple reproducing example:

import numpy as np
import polyscope as ps
import matplotlib.pyplot as plt

points_numpy = np.random.random((10,2))

# (1) Polyscope init
ps.init()
ps.register_point_cloud("my points", points_numpy)

# (2) Polyscope show
ps.show()

# (3) Matplotlib init
fig_samples = plt.figure()
ax_samples = plt.axes()
ax_samples.scatter(points_numpy[:, 0], points_numpy[:, 1])
ax_samples.set_aspect("equal")

# (4) Matplotlib show
plt.show()

I numbered the code sections to describe the different permutations. There are only 4!/(2!2!)=6 valid permutations so it's not too bad to just enumerate all of them.

If polyscope is initialized first (i.e., (1,2,3,4) or (1,3,2,4) or (1,3,4,2)), it mostly works fine. If polyscope is shown first, it'll still hang around after the close button is clicked and the matplotlib figure is still open, but other than that it works how I'd expect.

Now if matplotlib is initialized first, we run into problems. The order (3,4,1,2) also works fine, but (3,1,2,4) or (3,1,4,2) both cause the program to crash. Here's the output (I'm running this on an M1 Mac, macOS 13.3.1):

[polyscope] Backend: openGL3_glfw -- Loaded openGL version: 4.1 Metal - 83.1
2023-05-17 14:51:11.989 python3[2529:119090] *** Assertion failure in -[NSApplication run], NSApplication.m:3398
2023-05-17 14:51:11.991 python3[2529:119090] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSApp with wrong _running count'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007ff812e70be2 __exceptionPreprocess + 242
	1   libobjc.A.dylib                     0x00007ff81299875c objc_exception_throw + 48
	2   Foundation                          0x00007ff813ca6eb8 -[NSCalendarDate initWithCoder:] + 0
	3   AppKit                              0x00007ff815ddbddf -[NSApplication run] + 881
	4   _macosx.cpython-38-darwin.so        0x000000010c958472 show + 162
	5   python3.8                           0x00000001000a9962 cfunction_vectorcall_NOARGS + 98
	6   python3.8                           0x000000010017724c _PyEval_EvalFrameDefault + 48828
	7   python3.8                           0x0000000100048e3d _PyFunction_Vectorcall + 429
	8   python3.8                           0x000000010017724c _PyEval_EvalFrameDefault + 48828
	9   python3.8                           0x00000001000492be _PyFunction_Vectorcall + 1582
	10  python3.8                           0x000000010004fba7 method_vectorcall + 471
	11  python3.8                           0x00000001001757cf _PyEval_EvalFrameDefault + 42047
	12  python3.8                           0x00000001000492be _PyFunction_Vectorcall + 1582
	13  python3.8                           0x000000010017724c _PyEval_EvalFrameDefault + 48828
	14  python3.8                           0x0000000100169427 _PyEval_EvalCodeWithName + 727
	15  python3.8                           0x00000001001e0c48 run_mod + 168
	16  python3.8                           0x00000001001df775 pyrun_file + 133
	17  python3.8                           0x00000001001df320 pyrun_simple_file + 464
	18  python3.8                           0x00000001001df125 PyRun_SimpleFileExFlags + 53
	19  python3.8                           0x000000010020471e pymain_run_file + 286
	20  python3.8                           0x0000000100203f10 pymain_run_python + 416
	21  python3.8                           0x0000000100203d25 Py_RunMain + 37
	22  python3.8                           0x0000000100019558 main + 56
	23  dyld                                0x000000020050641f start + 1903
)
libc++abi: terminating due to uncaught exception of type NSException

I'm not sure if this is a polyscope issue, a matplotlib issue, or a combination of both, but it's perhaps something to look into. Thanks!

No repository files or tests are named. Start by running the supplied six permutations on the reported macOS setup, comparing Polyscope and matplotlib initialization and show behavior. Done means the combinations no longer crash and window behavior matches the expected ordering.