Simplification of exports system

[Akirathan]

The import/export system of Enso is one of the most complicated parts of the engine. Even after removing support for export all statements in #10369, it still feels unnecessarily complicated. Let's discuss some ideas, how can we make the exports even simpler.

It is important that imports will continue working exactly as they are working now. If any modifications to imports are necessary, they should be just a few minor fixes.

[Akirathan]

Allow exports only in Main modules

Currently, an export statement is allowed in arbitrary modules. Which enables multiple aliases for a single entity (module, type, method, ...) to be defined. If exports are allowed only in Main modules, there would be at most one alias for an entity. For example, Standard.Base.Dictionary is an alias for Standard.Base.Data.Dictionary.Dictionary, Standard.Base.True is an alias for Standard.Base.Data.Boolean.Boolean.True, and so on.

Note that all the imports that we have across the code base should continue working exactly as they are now, with possibly just a few minor fixes.

Apart from Prelude (which can be implemented differently to not use exports outside the Main module), I don't think there are any other, valid use cases that would prevent us from allowing exports only in main modules.

If this idea proves valid, I have another, even more controversial, suggestion. We could get rid of the export statement altogether, and specify the aliases in package.yaml. This is a follow-up idea that is not as important, however.

[radeusgd]

In what way is having at most 1 alias (so still multiple paths to the same entity are allowed) is better than having more aliases?

I do see some simplicity in not allowing aliases altogether, but don't see that much of a difference if we allow one or more alias per entity. There is some conceptual simplicity maybe, but does the max-1-alias limit have any practical implications - e.g. does it make any algorithms simpler?