Fix Save Value to File for large debugger strings (#9452)

[kamilkrzywanski]

Summary

• Keep shortened-string metadata in a strong HashMap so getShortenedInfo() still resolves after GC (previously a WeakHashMap could drop the entry while the truncated ... display value was still shown).
• Also resolve quoted Variable.getValue() forms ("content...") when looking up shortened info.
• Fixes Save Value to File writing only the first 100k characters plus ... instead of streaming the full remote string via StringInfo.getContent().

Fixes #9452

Test plan

• Debug an app with a String larger than 100_000 characters
• Open the variable custom editor (...) and choose Save Value to File
• Confirm the saved file length matches the full string (no trailing truncation ellipsis)

Standalone verification of the lookup failure mode:

• With WeakHashMap, after GC of the map key, lookup of an equal display string returns null → save would write the truncated preview
• With HashMap, lookup still succeeds → save can use getContent()

[matthiasblaesing]

What is the reason to switch from WeakHashMap to HashMap. The full strings are looked up by a string and if the key goes out of scope it makes sense, that the referenced value is removed.

[kamilkrzywanski]

@matthiasblaesing the WeakHashMap key is the shortened display string. Lookup often uses a different String instance (or a quoted Variable.getValue() form), so the entry can disappear while the UI still shows the truncated value and Save only writes that preview.

HashMap keeps it for the session; we still clear on last session remove. Also added quoted-form lookup.

[matthiasblaesing]

@kamilkrzywanski sorry for the late reply. I looked into this and while the changes improve the situation, it still felt off to me. The core problem for me is: Using string prefixes as keys for the full string. This is prone to collisions.

I stepped back and considered the situation from a different perspective: for short string we don't need special handling as the value itself can be fetched and we are done. Caching the strings can help performance though. Special casing is only needed for the long strings and for these the approach suggested by #9635 is to return a special object StringInfo that holds the shortened string and all the data that is required to fetch the full string.

Would you mind having a look at #9635 and test that approach? The nightly build is available from: https://github.com/apache/netbeans/suites/97240182404/artifacts/10773115996 (or via the checks page of the PR)