Keep exception and string display from populating string caches

[lagergren]

Rendering a StringHandle in a Java debugger populated its Java String cache. ExceptionHandle display did the same to its text handle, including when Java printed the wrapper exception's stack trace. This PR keeps the rendered text unchanged while leaving those caches alone.

Reproducer and debugger impact

A debugger that evaluates toString() can change the state being inspected:

1. Create a non-empty handle with xString.makeHandle(...). Its m_sValue cache is null.
2. Evaluate handle.toString(), as an automatic debugger renderer does.
3. Before this change, m_sValue now contains the string even though application code has not called getStringValue(). With this change, it remains null.

That can confuse investigation of when the cache is first populated: inspecting the handle itself warms the cache. ExceptionHandle.toString(), its WrapperException.toString(), and Java stack-trace printing have the corresponding text-cache path.

The reproduced impact is memoization during inspection. This PR does not claim a changed application result, a hang, or an uninitialized-layout crash. Display still allocates ordinary Java strings as needed.

Changes

• StringHandle.toString() reads an existing cached value, or creates the display string from its characters without storing it.
• ExceptionHandle.toString() keeps the ordinary getField(null, "text") read and quotes the string's characters without calling the memoizing getStringValue().
• HandleDisplayTest exercises the real display methods with actual handles from a NativeContainer and the installed XDK. It checks escaped output, initially empty caches, already populated caches, wrapper rendering, and Java stack-trace printing.

Field-access review

For a valid constructed ExceptionHandle, text is an existing ordinary field. Its composition
layout is prepared before construction, and GenericHandle initializes the corresponding field
array. getField(null, "text") therefore reads the stored value; it does not populate the
StringHandle's cache. Even an unassigned field value can be handled by the existing instanceof
check.

The unwanted mutation was in the subsequent getStringValue() call. There was no demonstrated
failure of this normal field read to justify a separate accessor. Both the speculative layout
guard and the peekField() helper are removed. GenericHandle, ClassComposition and
TypeComposition now have no net changes in this PR.

Verification

Final diff: 3 files, +110 / −6. The field-access simplification is
611fb1e9e.

After restoring the ordinary field read, the existing regression tests passed unchanged:
19 XDK cases, zero failures/errors/skips, including both display/cache cases. Formatting and
whitespace checks passed.

env RUN_INTEGRATION_TESTS=true ./gradlew :xdk:test --rerun --no-build-cache spotlessCheck --console=plain
git diff --check

The exception regression itself first reads getField(null, "text") and confirms that the
String cache is still empty. It then checks that handle display, wrapper display and Java
stack-trace printing leave the cache empty, and that an already populated cache is preserved.

The earlier before/after comparison temporarily restored the previous rendering methods.
Both cases failed at the cache assertion: expected null, but display populated the cache.
The output assertions preceding those checks passed. The temporary changes were restored.
That comparison tests the rendering change; it does not establish a need for an alternate
field accessor.

The tests use the distribution already provisioned by the XDK test task; no new build
dependency or silent skip was added.

Earlier broader verification at e650872 also passed: javatools 414 cases, 36 existing skips;
javatools_utils 120 cases, 2 existing skips; no failures or errors.