`Standard.Prelude` needed as `main = 6 * 7` no longer works

[JaroslavTulach]

In reflection of:

• Binary operator resolution based on that value #8779

Various operators are no longer exposed as builtins since #8779. As a result they are no longer available in programs without imports. E.g.:

main = 6 * 7

fails with Type_Error. The change in #8779 is desirable, as builtin operators have various restrictions and should be hidden from public (builtins don't support the "that conversion" introduced by #8779; they cannot be invoked as statics - #6282).

However the current limitations are unbearable. Basic operations with literals have to be available without any imports!

### Tasks
- [ ] Enable following TCK test: https://github.com/enso-org/enso/pull/8779#discussion_r1467850659

[JaroslavTulach]

Brainstorming

• we need some prelude
• we also need Enso runtime.jar to run on its own
• let's package a prelude into runtime.jar
• shall a prelude be subset of Standard.Base? Maybe, but what kind of subset?
• how hard is to select such subset?
• Standard.Builtins is small & encapsulated
• Isn't it easier to extend Standard.Buitins to include prelude?
• also it makes little sense for a @Builtin_Xyz to be distributed separately from runtime.jar
• require all builtins to be in Standard.Builtins, package that in runtime.jar and make it a prelude - related to Builtin methods shall not be publicly visible #6282 (comment)
• eliminate the need for test/micro-distribution when at it!

[JaroslavTulach]

A possible proposal:

Prelude in Standard.Builtins

Let's modify create a manually edited Standard.Builtins.Prelude module and re-export it from Standard.Builtins.Main. While Main is autogenerated, Prelude is going to be manually crafted and will include all the functionality that is currently missing from Enso builtins Integer.+ and other operators, Text.+ and other extension functions.

from project.Prelude import all
from project.Prelude export all

Standard.Builtins will be included when no other import is specified. There already is some support for "dual names": many types have their own Standard.Base name, but they also have Standard.Builtins name. When one adds an import statement, the name changes as witnessed by the need for this change.

@hubertp wrote:

an unfortunate workaround I had to add
The names in ConstantsGen are being generated in TypeProcessor

We can use the unfortunate workaround to define prelude!

importing stdlib means that builtin names are "overriden" by types properly defined in stdlib

That's ideal behavior for a default and optional prelude!

[JaroslavTulach]

In addition to * not being available, we also don't seem to know builtin types by default:

enso$ cat >x.enso
main = Integer

enso$ ./built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/bin/enso --run x.enso
x.enso:1:8: error: The name `Integer` could not be found.
    1 | main = Integer
      |        ^~~~~~~
Aborting due to 1 errors and 0 warnings.

e.g. neither Integer, Float, etc. are know. As far as I can tell this (mis) behavior is independent of #8779