Silence errors on ambiguous implicitly public imports when a different import
is explicitly public. In this case all imports are public so the ambiguity is
not dangerous and this configuration can happen during adoption of
access-levels on imports. Keep the error when an explicit import is package,
internal or below.
rdar://129037503
Adoption InternalImportsByDefault provides a safe access-level by default
to imports, as such ambiguities are not a risk and showing this warning is
superflous. When this warning is shown, make sure we note this alternative.
An import of a submodule implies an import of its top module, and
referenced decl will be associated with the top module. Make sure
we don't warn on public imports of a submodule being unused in API and
only report if the top module is unused.
Warn on imports of the same target module from the same source file when
they have different access-levels. This situation can lead to unexpected
behavior as the compiler will only take into account the most permissive
import.
In the following example, the module Foundation in functionally imported
as public. The `internal` modifier will be ignored. The new diagnostic
reports it as such.
```
public import Foundation
internal import Foundation // warning: module 'Foundation' is imported
as 'public' from the same file; this 'internal' access level will be
ignored
```
This could be an easy mistake to do when using scoped imports where this
diagnostic will also help.
rdar://117855481
