Find Python3 if not set in pybind11-config

[nicolecheetham]

Improves logic so Python3 will not be set by pybind11-config file unless a user has not already set the python version

Resolves #22051

---

This change is 

[nicolecheetham]

+@BetsyMcPhail for feature review please

Reviewable status: LGTM missing from assignee BetsyMcPhail, needs platform reviewer assigned, needs at least two assigned reviewers, missing label for release notes (waiting on @nicolecheetham)

[BetsyMcPhail]

Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: needs platform reviewer assigned, needs at least two assigned reviewers

[jwnimmer-tri]

I'll take on the platform review here.

[jwnimmer-tri]

The claim in the overview is "Resolves 22051". What evidence do we have to prove it is resolved?

The pre-merge tests do not seem to have any leverage to over the resolution (since no test code or configs were changed here), so in that case it is incumbent upon the PR author to explain in the pull review text somwhere what testing they performed to confirm the fix, presumably either as links to online test runs against this branch, or list(s) of manual commands that were run locally to confirm what happens.

If 22051 had a reproduction recipe clearly outlined then I could try it myself, but I couldn't tease out any reproducer from the posting.

[nicolecheetham]

@jwnimmer-tri I was thinking of procuring evidence by testing the drake-ros repo as Betsy brought to my attention it had the pybind11 issue in the past. Is there a way to locally test the drake-ros repository? Or do I have create an PR to test?

[jwnimmer-tri]

There is run_all_tests.sh but per the TODOs it doesn't actually run everything. (It's also possible that it has bitrotted, since I don't think it has any CI coverage.) But you probably don't need to test everything anyway -- the git repo has a bunch of different modules (kinda like drake-external-examples) and I imagine only one or two of them are relevant to this change. If you can find even one build or test that is failing when run vs Drake master, but passing vs this pull request, that would be sufficient.

Or, it's certainly fine to open a pull request against drake-ros if that is helpful for CI testing. Just mark it as "draft" and comment that it's only for some testing so nobody starts accidentally reviewing it. However, beware that some parts of drake-ros CI are probably known to be broken (unrelated to this Python3 problem), so also beware of false negatives.

In any case, if you had a bug reproducer that didn't involved drake-ros, that would probably be the easiest thing to test. I would hope that some project in drake-external-examples could demonstrate the bug, probably with a few tweaks to its CMakeLists.txt to be able to hit the problem.