Isolate rebuild directories per Clava instance

[lm-sousa]

Problem

CxxWeaver uses rebuild directories that are not owned by a weaver instance.

The first collision comes from REBUILD_WEAVING_FOLDERS in ClavaWeaver/src/pt/up/fe/specs/clava/weaver/CxxWeaver.java. It is a static ThreadLocal<Buffer<File>>. Two CxxWeaver instances that run on the same Java thread share the same two rebuild directories. Their rebuildAst() or rebuildFile() calls can delete or overwrite each other's generated files.

The second collision comes from $file.rebuild(). rebuildFile() writes all companion translation units to the fixed directory __clava_woven_for_file_rebuild. This directory is shared by every thread, weaver instance, and JVM process that uses the same working directory.

Clava-JS can host more than one Clava context in one JVM. Java thread ownership is therefore not the same as Clava instance ownership. A ThreadLocal does not isolate those contexts.

History and tested fix

Commit 3bd185daf1f58e2dd25ff3ad5b55be743ebb11a2 contained a broader shared-JVM isolation fix. Its rebuild-folder change made the two-folder buffer an instance field and replaced the fixed companion directory with a unique temporary directory.

The focused change was restored and tested on the Exploration branch in commit 40fdaac63b3c0d973a4144c0addc4fd51c1a1035.

Verification on that branch:

• :ClavaWeaver:compileJava passed.
• :ClavaWeaver:installDist passed.
• A runtime probe created two CxxWeaver instances in one JVM and confirmed that they owned different buffers and different __clava_woven_<UUID>_<user> directories.

Proposed change

• Store the rebuild-folder buffer in each CxxWeaver instance.
• Initialize a new buffer when that weaver resets.
• Use the instance buffer in rebuildAst() and rebuildFile().
• Give each rebuildFile() call a unique directory for companion translation units.
• Keep cleanup limited to directories owned by that invocation or weaver.

Why this matters

Without this change, parallel Clava-JS contexts and multiple Clava instances in one JVM can corrupt each other's syntax-check or rebuild inputs. The existing fixed companion directory also permits collisions between separate JVM processes launched from the same working directory.

Acceptance criteria

• Two CxxWeaver instances on the same Java thread never share rebuild directories.
• Two concurrent $file.rebuild() calls never share the companion-source directory.
• rebuildAst(false), rebuildAst(true), and $file.rebuild() retain their current behavior.
• Cleanup from one weaver cannot delete files used by another weaver.
• A focused shared-JVM regression test covers two Clava contexts that rebuild concurrently.

[lm-sousa]

I opened Issue #264 for the remaining cwd-relative cleanup risk.

#251 covers rebuild-directory ownership and isolation. #264 covers the separate leftover calls in CxxWeaver.close() that recursively delete fixed __clava_woven and __clava_src paths relative to the process working directory. Those calls can delete unrelated same-named user directories and are not removed by the rebuild-folder fix.

I kept this separate so the ownership fix and cleanup safety fix remain independently reviewable. The cleanup requirement in #251 should reference #264.