Allow using LongPackageName as LPN and change export conventions.

[LilithHafner]

Before:

julia> using Statistics as Stat
ERROR: ParseError:
# Error @ REPL[1]:1:6
using Statistics as Stat
#    └─────────────────┘ ── `using` with `as` renaming requires a `:` and context module
Stacktrace:
 [1] top-level scope
   @ none:1

After:

julia> using Statistics as Stat

julia> Statistics
ERROR: UndefVarError: `Statistics` not defined in `Main`
Suggestion: check for spelling errors or missing imports.
Hint: a global variable of this name also exists in Statistics.

julia> Stat
Statistics

julia> mean
mean (generic function with 6 methods)

This PR is implemented by

• No longer automatically export module names
• Explicitly loading module names on using (i.e. creates an explicit imported const binding)
• On using Mod as M, add Mod to the list of "used" modules and create an explicit imported binding M => Mod.

(non)breaking change 1

• Base.isexported(Statistics, :Statistics) will now return false (in Julia <=1.10 Base.isexported was not part of the public API)
• Base.ispublic(Statistics, :Statistics) will now return false (in Julia <=1.10 Base.public was not defined)

Breaking change 2

names(Mod) currently no longer includes :Mod, I'd like to stop implicitly marking the module itself as public because I don't think Statistics.Statistics is something that should be public by default. Specifically, I think that in the package M1,

module M1
    public API
    const API = M2
    module M2
        public f
        f() = 0
    end
end

The code M1.API.M2.f() depends on internals (the name of the module M2, which was never marked public)

Breaking change 3

The code

julia> module M1
           module M2
           end
       end
Main.M1

julia> module M2
           using ..M1.M2
       end
Main.M2

julia> M2.M2 === M1.M2
false

julia> M2.M2 === M2
true

now throws on

julia> module M1
           module M2
           end
       end
Main.M1

julia> module M2
           using ..M1.M2
       end
ERROR: invalid redefinition of constant M2.M2

because the using statement tries and fails to create an explicit binding. This is a code pattern that is currently in use in Pkg.jl, but I do think it's a bit of an antipattern, and this PR creates a great workaround. However, maybe we should downgrade that into a warning.

Implements #52784 (resolves #52784)
Fixes #52817, Fixes #38521
Is a superset of and therefore closes #52810 (NFC)

Depends on JuliaLang/JuliaSyntax.jl#406
Depends on JuliaLang/Pkg.jl#3750

[LilithHafner]

I'm open to more test cases, this is surprisingly finicky.

[LilithHafner]

Dropping this link here as a TODO once we update JuliaSyntax and unblock this PR: review this discord thread and consider if/how the changes here impact that situation. EDIT: this PR would help that situation a wee bit but not address it much.

[LilithHafner]

Tagging triage because this would be a significant new syntax feature.

[StefanKarpinski]

I like this feature and think we should have it. Someone needs to implement.

[StefanKarpinski]

Triage likes it. My argument in favor of making using Foo create an explicit const binding for Foo is that the implicit bindings are for things that you didn't explicitly ask for, but you did explicitly ask for Foo! Of course, as it stands, you might have a situation where you want the things exported by Foo but want to use the name Foo for something else... enter using Foo as F which lets you pick a different name for Foo so that you can use the Foo name yourself. So it makes sense for these changes to go together. @xal-0 noted that this eliminates an annoying special case for the Main module, which is a nice side effect.

One additional feature I'd like to see is that using Foo as _ skips creating a binding for Foo altogether.

[DilumAluthge]

What is the intended use case here? In the REPL, or in package code?

[LilithHafner]

Both, same as import Mod as Alt.

[DilumAluthge]

But (unlike import Foo as Bar), this new syntax will bring all the exported names into scope, right?

I’m not thrilled about this. I don’t really think we should add new syntax that encourages people to disregard #42080 in package code.

[DilumAluthge]

Also, FWIW, it wasn’t immediately obvious to me at first (just from looking at the syntax) that using Foo as Bar brings all the exported names into scope. So in theory that’s another potential footgun (people not realizing that they’re bringing all those names into scope).

But that may just be me personally.

I think I’m more concerned about the #42080 aspect.