Fail compilation if multiple conflicting top-level private defs/vals are in the same package

[jchyb]

Fixes #22721
Now the private top level definitions act basically the same as package private. To be honest, I am not completely certain that this is what's supposed to happen here, but:

• it would make the top level definitions access modifiers act the same as for class/objects
• that's what the reference seems to imply: https://docs.scala-lang.org/scala3/reference/dropped-features/package-objects.html:

3. The notion of private is independent of whether a definition is wrapped or not. A private top-level definition is always visible from everywhere in the enclosing package.
4. If several top-level definitions are overloaded variants with the same name, they must all come from the same source file.

Private top level definitions should be visible from other files (as long as they share a package), and if multiple share the same name, they should be in the same files (so it seems they should error out if found in different files).

[jchyb]

Looks like the https://github.com/scala/scala3/blob/main/tests/neg/toplevel-overload/moredefs_1.scala test case claims otherwise

[jchyb]

community-build run results: https://virtuslab.github.io/community-build3/2025/03/12/3.7.0-rc1-20250310-f0284d0-snapshot.html
We are shown a number of failing projects here, but none seem related to the fix here (most relate to sbt not being able to parse the version string).

[jchyb]

At the core meeting we talked about making sure this also behaves like conflicting objects/classes would in separate compilation (where with the help of incremental compilation, they are able to throw the error), which I needed to recheck. It looks like it currently does not, even for public definitions: #22804.

I think it should be safe to merge this anyway, since the error happened for public definitions too, and I do not believe this is something we can fix in the compiler itself (as I try to explain the the issue).