Added parallelization to PreprocessShortestPath.

[adityapande-1995]

This PR tries to resolve #21705 by parallelizing the MathematicalProgram solving. I'm not sure if this solves the problem, but I'm open for suggestions :)

---

This change is 

[jwnimmer-tri]

\CC @cohnt FYI

[jwnimmer-tri]

A few big picture points:

(1) Drake avoids unbounded parallelism. Every multicore par-for loop must always have a governor for max number of cores. Typically this a Parallelism parallelism argument with a default value. Then the loop implementation must respect that upper limit.

(2) For binning work across cores, we typically use our StaticParallelForIndexLoop wrapper (not direct calls to std::async) except in extreme cases where the work is extremely large, lumpy chunks. My (possibly wrong) first impression of the preprocessing is that is not very large nor lumpy.

[jwnimmer-tri]

(3) For efficiency, there should be one mathematical program per core, not one program per edge.

[AlexandreAmice]

Related issue is #19119. Perhaps resolving there would be more appropriate than having ad-hoc parallelization of solving MathematicalPrograms scattered throughout Drake.

Reviewable status: LGTM missing from assignee jwnimmer-tri(platform), needs at least two assigned reviewers, commits need curation (https://drake.mit.edu/reviewable.html#curated-commits), missing label for release notes (waiting on @adityapande-1995)

[RussTedrake]

FYI -- I just commented on #21705, but I also think that this specific codepath is likely to change soon (#21341). This particular code optimization might become irrelevant once we do that.

[RussTedrake]

Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: LGTM missing from assignee jwnimmer-tri(platform), needs at least two assigned reviewers, commits need curation (https://drake.mit.edu/reviewable.html#curated-commits), missing label for release notes (waiting on @adityapande-1995)