Use slf4j in instrument non-guest code

[JaroslavTulach]

Pull Request Description

• based on experiments made in Reschedule guest code execution into dedicated thread pool #12613 that are by themselves motivated by Upgrading to Truffle libraries 24.2.0 #12500
• TruffleLogger shall only be used in the interpreter running guest code
• most of the code in runtime-instrument-xyz projects is not running a guest code
• most of the code in these instruments schedules runs of guest code
• thus using TruffleLogger isn't appropriate and it yields exception when it cannot find EnsoContext around
• let's make the code ready for context not being around
• let's use SLF4J instead of TruffleLogger

Checklist

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

• All code follows the
  Scala,
  Java,
• Unit tests updated to continue to pass

[hubertp]

Welcome to the dark side

[hubertp]

All our logs are now broken:

[DEBUG] [2025-03-26T17:07:33.631] [org.enso.languageserver.requesthandler.text.ApplyEditHandler] stopped
[TRACE] [2025-03-26T17:07:33.631] [org.enso.interpreter.instrument.execution.ReentrantLocking] Waited [[Ljava.lang.Object;@48e19ca2] {}ms for the {}
[TRACE] [2025-03-26T17:07:33.631] [org.enso.interpreter.instrument.execution.ReentrantLocking] Waited [[Ljava.lang.Object;@ea44313] {}ms for the {}
[TRACE] [2025-03-26T17:07:33.631] [org.enso.interpreter.instrument.command.Command] Adding pending file [[Ljava.lang.Object;@7d8d303e] edits [{}] and IdMap of length {}
[TRACE] [2025-03-26T17:07:33.631] [org.enso.interpreter.instrument.execution.ReentrantLocking] Kept pending edits lock [[Ljava.lang.Object;@405a9f84] for {}ms
[DEBUG] [2025-03-26T17:07:33.631] [org.enso.interpreter.instrument.execution.ReentrantLocking] Kept file lock [[Ljava.lang.Object;@d2247] for {1}ms

[Akirathan]

All our logs are now broken:

Right. Because slf4j logger has different API than java.util.logging logger. slf4j logger accepts vararg for arguments, wherease java.util.logging accepts Object[]. This means that every logging method call that passes new Object[]{...} should be rewritten to the vararg variant.

[JaroslavTulach]

This must have been broken as java.util.logging.Logger doesn't recognize {} as a variable placeholder.

[JaroslavTulach]

All our logs are now broken:
slf4j logger accepts vararg for arguments, wherease java.util.logging accepts Object[]

I see. I'll fix it:

• having two logging systems/formats along each other may be confusing
• mistakes had already been present
• now we have the vararg mistakes

How to detect the errors?

• only errors f954fca will be addressed
• e.g. only added lines in the commit
• but we need to take a look at surrounding lines as well as new Object[] is often placed on a separate line

git show f954fca22fca9158b3e8126c1ccc6673e10c9bd9 | grep ^+ -C2 | grep new.*Object -C20

yields few candidates. But then we also log from scala and following command gives plenty:

git show f954fca22fca9158b3e8126c1ccc6673e10c9bd9 | grep ^+ -C2 | grep Array -C20

• Use varargs when logging arguments to slf4j #12661 is ready for your consideration