[lldb] lldb zero-fills unavailable DW_OP_piece fragments instead of preserving optimized-out state

LLDB currently materializes an unavailable `DW_OP_piece` fragment as concrete zero bytes.

That loses the fact that the fragment is unavailable and can turn a partially optimized-out composite location into an invented concrete value.

I am using a DWARF expression directly here because it is easier to understand and maps directly to the DWARF location-description rules.

A simple example illustrating the behavior is:

```text
DW_OP_piece 1
DW_OP_const1s -1
DW_OP_stack_value
DW_OP_piece 3
```

This should be read as a composite location with an unavailable leading 1-byte fragment and a concrete trailing 3-byte fragment whose bytes are `0xff`.

So the result should preserve partial unavailability. It should not invent a fully concrete 4-byte integer value.

GDB preserves that distinction and reports the affected fragment as ``.

LLDB instead materializes the unavailable byte as `0x00`. On a little-endian target, that turns the 4-byte value into `0xffffff00`, which is the concrete integer `-256`.

That is not just a presentation difference. It changes an unavailable fragment into a made-up concrete value.

So the unavailable leading fragment is not merely displayed differently; LLDB turns it into a concrete byte pattern and reports a wrong value.

While reviewing [lldb/source/Expression/DWARFExpression.cpp](https://github.com/llvm/llvm-project/blob/main/lldb/source/Expression/DWARFExpression.cpp), specifically `Evaluate_DW_OP_piece`, I noticed that the empty-stack piece path does exactly this:
- it treats the current piece as "not available."
- it resizes the piece buffer
- it fills the buffer with zeros using `memset(...)`

The source comment immediately below already says:

> "0" is not a correct value for the unknown bits.

So the current behavior appears to be a known placeholder that leaks into user-visible evaluation results.