GeezerVison

This is a large change that involves refactoring the code that loads extension modules. The objective is partly to improve the clarity of the code, but mostly it's so that I can execute a subset of the constituent operations in a subsequent PR.

The changes include:

• ...

While this aligns with the sort of thing I've wanted to do for a long time, the main motivation at the moment is to drastically reduce the likelihood of problems from loading a single-phase init extension module in an isolated subinterpreter. Nearly all the changes here come from what I found I needed for a (relatively) simple solution to the isolation problem. Consequently, much of the refactoring follows the natural divisions in the flow of operations when loading an extension module.

For the sake of reducing the burden of code review for such a large change, I have purposefully avoided changing any behavior in this PR, regardless of how benign it might seem. That said, if it's still too much I'm okay with splitting this up.

For context, this is the first of 3 branches in a chain. Here are the other two, in order:

• track-all-ext-modules - actual (small) changes in behavior that I didn't put in this PR
• load-ext-in-main-interp-2 - always load modules in the main interpreter first (supercedes gh-117487)

• Issue: Single-Phase Init Extension Module Init Functions Still Run in Isolated Interpreters #117953