Consider moving out-of-line module loading from parser to expansion

[petrochenkov]

Due to module loading parser has to do some not very appropriate for a parser things like

• expanding cfgs on modules (duplicated with expansion)
• keeping the current filesystem position (duplicated with expansion)

We also don't really need to load those files until we need to incorporate their contents into NodeId-entified AST, which happens during expansion.

The move will also mean never loading files in unconfigured code.
The loading is currently skipped only if cfg is placed directly on the mod m;, but not in other cases like

#[cfg(FALSE)]
mod m {
    mod n; // Still loaded
}

[matklad]

This is on my todo list, as it is a per-requisite for moving parser into a library.

[petrochenkov]

The PR trying to split the libsyntax crate apart (#65324) has to use some hacks due to cfg-expansion being called from the parser.

[Mark-Simulacrum]

#66565 removes those hacks in favor of a less principled approach (revealing the tight coupling between cfg expansion and parsing).

[Zoxc]

I would like the ability to start parsing immediately when we see a mod name;, but I guess the parser could just check if any #[cfg(..)] are in scope.