simplify the active_module implementation and make it a "Base feature"

[KristofferC]

The current implementation of active_module is REPL instance specific but it becomes confusing since Base has to try reach out for a REPL to ask it what the active module is. There is also things like a global previous_active_module which shows that the REPL instance specific implementation is a best effort at best.

This simplifies things by making the active_module a Base feature (just a global value) and then anything (including the REPL) can set that.

Should fix #54888, #54780.

[JeffBezanson]

This doesn't make sense to me, since which module a REPL is eval'ing in is indeed a property of that REPL --- to the extent you can have multiple REPLs, they can be talking to different modules. Meanwhile, Base has a separate notion of a current active REPL (Base.active_repl) so it seems to me the "active module" must be the module of that REPL.

Even better, maybe we can delete active_module and only use the module property of the IOContext.

[vtjnash]

SGTM. It is used in a lot of places that are not associated with the REPL, such as Enums, Docs, InteractiveUtils.varinfo, to just list things in this respository

[vtjnash]

I don't know if we should delete this, as some REPL instances might not want to use the global active_module. Or could be nullable?

[KristofferC]

Even better, maybe we can delete active_module and only use the module property of the IOContext.

That sounds nice indeed but the following places do not take an IO:

• varinfo
• doc!
• dump