[lldb] lldb resumes DWARF expression decoding from DW_OP_bra / DW_OP_skip targets inside another operation's operand bytes

While reviewing DWARF expression control flow, I noticed that LLDB appears to treat a `DW_OP_bra` or `DW_OP_skip` destination as any in-range byte offset within the current expression.

One compact example is:

```text
DW_OP_skip +1
DW_OP_const1u 0x37
DW_OP_stack_value
```

The decoded target lands on the payload byte `0x37` of `DW_OP_const1u`, not on the first byte of a separately encoded operation.

If the destination lands inside the operand bytes of a later operation, LLDB continues decoding from that byte as if it were a fresh opcode.

I realize the [DWARF v5](https://dwarfstd.org/doc/DWARF5.pdf) text defines these branch offsets in bytes, and I have not found an explicit sentence saying that the destination must be the first byte of an operation. This appears to be a standards-interpretation question rather than a clear-cut conformance bug.

Still, the behavior seems surprising. DWARF describes an expression as a stream/sequence of operations, where each operation consists of an opcode followed by zero or more operand bytes. Against that model, resuming execution in the middle of another operation's encoded operands seems at least worth validating explicitly or clarifying.

More concretely, DWARF v5 Section 2.5 presents a DWARF expression as an encoded stream of operations whose operand layout is determined by each opcode, and DWARF v5 Section 7.7.1 presents the expression bytes as a sequence of operations, each with a 1-byte opcode followed by its additional data bytes. Those do not explicitly forbid an interior branch target, but they do describe the expression as an already structured sequence of operations. That is why decoding from the middle of another operation's operand bytes stood out.