Fix Logger's name in stdlib

[hubertp]

Pull Request Description

Somehow SLF4J is able to recognize correctly the provided Logger's name and print it to the user. Java's Logger is
not.
In addition, we setup SLF4J's configuration, meaning that log-levels are correctly respected.

For a simple project:

from Standard.Base import all
from Standard.Base.Logging import all

type Foo

main =
    IO.println "Hello World!"
    Foo.log_message level=..Warning "I should warn you about something..."
    Foo.log_message level=..Info "Should be seen? By default we only show up-to warnings level"
    Foo.log_message level=..Severe "Something went really bad!"

This change demonstrates the fix.

Before:

> enso --run simple-logging.enso
Hello World!
Nov 08, 2024 6:08:07 PM com.oracle.truffle.host.HostMethodDesc$SingleMethod$MHBase invokeHandle
WARNING: I should warn you about something...
Nov 08, 2024 6:08:07 PM com.oracle.truffle.host.HostMethodDesc$SingleMethod$MHBase invokeHandle
INFO: Should be seen? By default we only show up-to warnings level
Nov 08, 2024 6:08:07 PM com.oracle.truffle.host.HostMethodDesc$SingleMethod$MHBase invokeHandle
SEVERE: Something went really bad!
Foo

After:

> enso --run simple-logging.enso
Hello World!
[WARN] [2024-11-08T18:03:37+01:00] [simple-logging.Foo] I should warn you about something...
[ERROR] [2024-11-08T18:03:37+01:00] [simple-logging.Foo] Something went really bad!
Foo

Important Notes

Closes #11262.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[radeusgd]

Thanks for resolving this! 🎉

[radeusgd]

I'm wondering if there's some reasonable way to test this? But I assume we don't have utils to intercept the logs from within Enso tests?

Perhaps we could write a JUnit test in runtime-with-instruments that would call the log methods and then inspect the outputs? It would be a nice to have to prevent regressions.

[hubertp]

Perhaps we could write a JUnit test in runtime-with-instruments that would call the log methods and then inspect the outputs? It would be a nice to have to prevent regressions.

I will think about it.

[hubertp]

As a bonus, stdlib logger respects log levels specified by the user:

> enso --log-level info --run simple-logging.enso 
[INFO] [2024-11-11T10:50:24+01:00] [org.enso.interpreter.runtime.DefaultPackageRepository] Found library Standard.Base @ 0.0.0-dev at [***/0.0.0-dev].
Hello World!
[WARN] [2024-11-11T10:50:29+01:00] [simple-logging.Foo] I should warn you about something...
[INFO] [2024-11-11T10:50:29+01:00] [simple-logging.Foo] Should be seen? By default we only show up-to warnings level
[ERROR] [2024-11-11T10:50:29+01:00] [simple-logging.Foo] Something went really bad!
Foo

[hubertp]

Perhaps we could write a JUnit test in runtime-with-instruments that would call the log methods and then inspect the outputs? It would be a nice to have to prevent regressions.

I will think about it.

Added.