SecureJavascriptConfigurator maxMemoryUsed does not work (accurately)

**Describe the bug**
When running Script tasks and enabling [maxMemoryUsed](https://github.com/flowable/flowable-engine/blob/main/modules/flowable-secure-javascript/src/main/java/org/flowable/scripting/secure/SecureJavascriptConfigurator.java#L74-L77) the underlying Javascript engine (Rhino) will periodically call observeInstructionCount in [SecureScriptContextFactory](https://github.com/flowable/flowable-engine/blob/main/modules/flowable-secure-javascript/src/main/java/org/flowable/scripting/secure/impl/SecureScriptContextFactory.java#L72-L97) which then uses (JVM specific) ThreadMXBean to calculate the currently allocated bytes for the thread executing the script.

This all is technically correct, but does not take **garbage collection** into account in any way, leading to the reported 'allocated bytes' value to be (sometimes significantly) higher than _retained_ bytes for the script after a garbage collection is performed. As long as the JVM has enough heap space available, it might choose to not perform garbage collection at all.

If System.gc() is forced on every _ observeInstructionCount_ call, a test script (busy loop that just allocates some variables inside the loop) runs for minutes before reaching the memory limit, while without forcing a gc the script terminates within seconds (with a memory limit of 128MB).

**Expected behavior**
The script is terminated only when it uses more memory than the configured limit, taking garbage collection into account.

I believe this is not possible to implement. If nothing else, the documentation for this feature should clearly state that it is not _used memory_ but more close to _allocated memory_ that is limited.

**Additional context**
Flowable 7.0.1, with Spring Boot

Also worthy of note, the current implementation will report -1 when used with Java 21 Virtual threads ; ThreadMXBean.getThreadAllocatedBytes(threadId) does not support virtual threads.

Inizia con SecureJavascriptConfigurator.java e SecureScriptContextFactory.java, quindi traccia il percorso con cui maxMemoryUsed raggiunge observeInstructionCount e ThreadMXBean. Verifica il comportamento relativo alla garbage collection e ai thread virtuali di Java 21, e determina se il risultato debba essere un'implementazione corretta o una documentazione più chiara dei limiti di memoria allocata.

Scritto dal modello di indicizzazione a partire dal testo della issue.