spirv-objdump --source incorrectly extracts SPIR-V string operands

### Description

SPIRV-Tools 2026.3~rc1 has a problem in
`tools/objdump/extract_source.cpp` when extracting SPIR-V string operands.

`ExtractStringLiteral()` currently treats the string operand as a byte range
obtained by `reinterpret_cast` from the SPIR-V word array.

SPIR-V string operands are encoded as 32-bit words, with characters packed
into the bytes of those words. The string should therefore be decoded
explicitly from the 32-bit words in SPIR-V byte order.

There is also an issue with `OpSourceContinued`: its extracted string needs
to be appended to the preceding `OpSource`/`OpSourceContinued` source rather
than replacing the existing output.

### Affected version

SPIRV-Tools 2026.3~rc1

### Component

`tools/objdump/extract_source.cpp`

### Expected behavior

`spirv-objdump` should correctly reconstruct source text from `OpSource` and
one or more `OpSourceContinued` instructions.

### Fix

The attached patch changes `ExtractStringLiteral()` to:

- accept a `uint32_t` word range;
- decode four bytes from each SPIR-V word in order;
- stop at the first NULL byte;
- preserve the existing escape handling;
- optionally append to an existing output string.

It also makes `OpSourceContinued` append to the preceding source.

### Testing

After applying the change:

```text
[==========] 9 tests from 1 test suite ran.
[ PASSED ] 9 tests.

The complete SPIRV-Tools test suite was also run:

[==========] 7636 tests from 406 test suites ran.
[ PASSED ] 7636 tests.

3 disabled tests.

Patch
extract_source.clean.patch
SHA-256: 353128a2971b42fc9061b04054c20a8d71af16b74aa96ab016f390658e044491

### Observed failure

While building Mesa on a big-endian system, the SPIR-V toolchain reports:

```text
error: line 11: Invalid extended instruction import ‘nepOs.LC’

The string nepOs.LC is the byte-swapped representation of
OpenCL.s.

This appears to be related to SPIR-V string operands being interpreted as
bytes rather than as 32-bit SPIR-V words on a big-endian system.

### Related real-world failure

A similar failure was observed while building Mesa 26.1.6 on the Debian
buildd infrastructure:

```text
FAILED: [code=1] src/nouveau/vulkan/nvkcl.spv
.../mesa_clc -o src/nouveau/vulkan/nvkcl.spv ...
(file=input,line=0,column=0,index=6): Invalid extended instruction import 'nepOs.LC'

The reported extended instruction import is nepOs.LC, which appears to be
the byte-swapped representation of OpenCL.s.

This was observed in a Debian buildd environment and is not a failure from
the local SPIRV-Tools test environment used to verify the attached patch. I did a build of mesa myself and observed the same problem.
It is included as an example of the kind of big-endian SPIR-V string handling
problem that motivated investigating this code.
https://buildd.debian.org/status/package.php?p=mesa&suite=sid#problem-3

[extract_source.clean.patch](https://github.com/user-attachments/files/31347527/extract_source.clean.patch)

Start with tools/objdump/extract_source.cpp and the existing source-extraction tests; the issue reports a focused 9-test suite. Verify that SPIR-V string operands decode in word order, preserve escape handling, and that OpSourceContinued appends to prior source text, then run the focused tests and the full SPIRV-Tools suite.

Written by the indexing model from the issue text.