sim: Ensure custom import machinery doesn't hide builtin modules

[edwinbalani]

Description

There have been a couple of reports in the badge channel of weird failures to import Python standard library modules while trying to start the simulator, in September and again today. I wrote off the first as a weird/broken Python installation, even though I'd noted there were some importlib shenanigans going on in sim/run.py, but the second occurrence (happening to another person) led me to look closely at the shenanigans.

I think these changes are the fix required to the sim's custom meta path finder. However I haven't worked on one of these before and I'd appreciate some eyes and more diverse testing than just my system.

Issue links

Resolves #278 - even though this issue was closed by the author, a ModuleNotFoundError trying to import _ast is exactly the reported issue in the second occurrence reported on the badge channel, so I'm fairly sure the cause is the same.

[edwinbalani]

I couldn't find an obvious other json or tarfile that would have been found if we didn't do this workaround. However, out of the sys.path entries that the sim adds below, I don't have a .../build-tilgdagon/frozen_mpy (presumably I have to compile something).

Does anyone know if a json/tarfile in that location is what these lines are trying to avoid?

[edwinbalani]

Here's the explanation I wrote in the commit message description - worth a fact-check by anyone who knows better, particularly as to the intent of the UnderscoreFinder:

The UnderscoreFinder is intended to override the import-time finding of
selected modules, but it is implemented by completely wrapping the
original BuiltinImporter that would be found in sys.meta_path at
startup.

Therefore the UnderscoreFinder is obliged to pass through all
find_spec() calls that it doesn't otherwise override, to avoid
accidentally breaking importation of other modules.

(It doesn't have to consult the wrapped PathFinder by default, because
we add another PathFinder to sys.meta_path.)