pre-safe-import-hooks: gracefully handle cases when six is unavailable

[rokm]

In pre-safe-import hooks that deal with six (or vendored six), gracefully handle the cases when the six module is unavailable.

In general, the pre-safe-import hooks might end up being called for non-existent modules, and the hooks need to account for that (even though the behavior seems to depend on how the missing module is imported).

For example, a program with a duplicated import,

import six.moves
import six.moves

seems to end up triggerring the six.moves pre-safe-import hook on the second import. The same happens in more complex scenarios where these imports are scattered across different modules.

[rokm]

This is something that came up in pyinstaller/pyinstaller-hooks-contrib#666, where the introduced thorough import analysis ends up triggering the six.moves pre-safe-import hook.

The pre-safe-import hooks may in fact be called even if their corresponding module cannot be found by modulegraph - this is the mechanism that our gi.repository.* hooks (pre-safe-import and standard hooks) rely on.

The actual behavior of this particular case (missing parent package and actual hook's sub-package) seems to depend on import order (i.e., whether parent package (six) has already been determined to be missing or not). For example

import six.moves
import six.moves

triggers the hook.

import six
import six.moves

does as well.

But

import six.moves
import six

does not.

[rokm]

Slight revision - I realized that if we cannot import six, we should probably not be creating the run-time package entry for six.moves in the modulegraph, either. This is mostly for the sake of consistency.