Fix byte/character offset mixup in computed constants output

[rootkiller6788]

Problem

When jsir_gen runs dynamic constant propagation on a script containing non-ASCII characters (e.g. Cyrillic text in a comment), the Computed constants section reports the wrong source segment.

Fixes #22.

Root cause

DumpJsirAnalysisResult in maldoca/js/ir/jsir_gen_lib.cc formats each computed constant with From [start, end): ... by calling original_source.substr(start_offset, end_offset - start_offset). However:

• original_source is the raw UTF-8 byte string.
• start_offset / end_offset are UTF-16 code-unit offsets. They come from JsirTriviaAttr locations, which are populated from Babel/ESTree positions (node->start() / node->end() in ast_to_jsir.handwritten.cc). ESTree source positions are UTF-16 code units.

Slicing a byte string with code-unit offsets diverges as soon as any non-ASCII character appears before the constant, producing the misaligned output described in the issue.

Fix

Convert the source to UTF-16 once with the existing Utf8ToUtf16 helper, slice it using the UTF-16 offsets, and convert the selected segment back to UTF-8 with Utf16ToUtf8 for output. Adds the :utf16 dependency to the jsir_gen_lib BUILD target.

Testing

Manual verification of the logic: offsets recorded by the analysis are UTF-16 code-unit offsets (confirmed against pass.cc and the Babel position provenance), and the fix applies the existing, already-used Utf8ToUtf16 / Utf16ToUtf8 round-trip so byte offsets and code-unit offsets no longer get conflated.