AutoOpen in the empty namespace as malicious code vector

I noticed this while trying to excise unexpected uses of YoLo.fs in projects that depend (even if only transitively) on Http.Fs: https://github.com/haf/Http.fs/issues/176 . While this particular case does not appear to be malicious, and merely makes it harder to remove the dependency, it is easy to see how it could be exploited in a malicious way.

Typically an `AutoOpen` attribute is declared on a module in a nonempty namespace, so that `open`-ing the namespace will implicitly open the module. Of course, consumers of external packages should always take care when using `open` declarations of external packages' namespaces and modules. However, in the empty namespace, this will happen unconditionally with no `open` usage at all, and, since there is currently no good standard way to disable transitive NuGet package references ( https://github.com/dotnet/sdk/issues/11803 ), the `AutoOpen` will *transitively infect all packages and projects that depend on the offending package*.

While the F# style guide advises programmers to take care in using `AutoOpen` and `RequireQualifiedAccess` in their own code, there is nothing stopping a library author from abusing `AutoOpen` in this way to e.g. typo-squat a malicious definition onto a standard type or module and infecting even codebases that are very careful about managing their dependencies.

I propose that the compiler should not honor `AutoOpen` declarations on modules declared in the empty namespace.