feat: add StringReference.GetValue/GetRaw (Python parity)

[tinysec]

Summary

Closes HIGH-severity convenience gap #4. Python's StringReference exposes .value (decoded text) and .raw (raw bytes) (binaryview.py:510/:514). The C# StringReference is a handle-less Type/Start/Length carrier, so callers had to separately ReadData(Start, Length) and hand-decode per StringType.

Changes

Two durable extension methods in NavigationExtensions.cs (composition-only, no P/Invoke, no generated-file edits), plus a StringType → Encoding table mirroring Python's _decodings:

StringType	Encoding
AsciiString	Encoding.ASCII
Utf8String	Encoding.UTF8
Utf16String	Encoding.Unicode (UTF-16 LE)
Utf32String	Encoding.UTF32 (UTF-32 LE)

• GetRaw(sref, view) → view.ReadData(Start, Length).
• GetValue(sref, view) → decodes GetRaw with the type's encoding using .NET's default replacement fallback (the equivalent of Python errors='replace').

The view is a parameter (not stored on StringReference) because the C# type is a value carrier; storing a view would force a FromNative signature change threaded through the TakeStructArray pipelines, so composition-only extensions are cleaner. Python's .view property is therefore N/A here — the caller already holds the view.

E2E test (harness repo)

GetValueAndRawAreConsistentForEveryStringTypePresent — runs analysis (the string list is materialized lazily), then for a sample of the 177 strings asserts GetRaw reads exactly [Start, Start+Length) and GetValue decodes with the independently-computed expected encoding. cat.bndb yields 176 ASCII + 1 UTF-16 strings, so the test exercises both Encoding.ASCII and Encoding.Unicode dispatch — a wrong table entry would diverge for the UTF-16 string. Full harness regression 52/52.