Parallelize the Pairwise Set Intersection Checking for GCS (with or without Continuous Revolute Joints)

[cohnt]

Closes #21351. (Although once we have a parallelism option added to GCS, as is being discussed in #21965, we should make sure that gets plumbed through.)

Note that the parallelism here is used in two ways -- the computation of AABBs of the constituent sets is handled with a parallel for loop, and then the pairwise intersections themselves are checked with SolveInParallel.

This leads to significant speedups, especially on faster graphs. With 224 sets (resulting in 5928 edges), we have the following computation times:

Parallel? No AABB Preprocessing? No     Runtime: 1.174356460571289
Parallel? No AABB Preprocessing? Yes    Runtime: 1.1098930835723877
Parallel? Yes AABB Preprocessing? No    Runtime: 0.2572915554046631
Parallel? Yes AABB Preprocessing? Yes   Runtime: 0.2135148048400879

With 1120 sets (resulting in 152680 edges), we have the following computation times:

Parallel? No AABB Preprocessing? No     Runtime: 26.704376697540283
Parallel? No AABB Preprocessing? Yes    Runtime: 19.698741912841797
Parallel? Yes AABB Preprocessing? No    Runtime: 4.901020050048828
Parallel? Yes AABB Preprocessing? Yes   Runtime: 3.577193021774292

(This is on my personal computer, with 20 threads.)

+@sadraddini for feature review, if you have the time.

---

This change is 

[cohnt]

+@sammy-tri for platform review please

[sammy-tri]

@drake-jenkins-bot linux-jammy-clang-bazel-experimental-thread-sanitizer please @drake-jenkins-bot linux-jammy-clang-bazel-experimental-valgrind-memcheck please @drake-jenkins-bot linux-jammy-clang-bazel-experimental-undefined-behavior-sanitizer please @drake-jenkins-bot linux-jammy-clang-bazel-experimental-address-sanitizer please

[cohnt]

Thanks for tracking down the root cause! Should we document somewhere that this is a footgun one needs to worry about when deprecating (potentially) multithreaded code?

[jwnimmer-tri]

bindings/pydrake/geometry/geometry_py_optimization.cc line 1463 at r1 (raw file):

... there's a call into WarnDeprecated when the function is run, which tries to redirect the output through python with the GIL released, and there's our segfault.

Thanks for tracking down the root cause! Should we document somewhere that this is a footgun one needs to worry about when deprecating (potentially) multithreaded code?

It was a bug in the wrapper, so we'll fix the bug (and then no docs needed):

=> #22195