[lldb] Clarify DWARF expression opcode handling in DWARFExpression::Evaluate

## Summary

While reviewing DWARF expression opcode handling in [lldb/source/Expression/DWARFExpression.cpp](https://github.com/llvm/llvm-project/blob/main/lldb/source/Expression/DWARFExpression.cpp), I noticed that some DWARF opcodes (e.g., `DW_OP_reinterpret`) are recognized by decode-side helper logic, such as `GetOpcodeDataSize`, but do not appear to have explicit handling in the main `DWARFExpression::Evaluate` switch in the same file.

As a result, these opcodes appear to be known to LLDB during decoding, but during evaluation, they fall through to the generic `default` path rather than an opcode-specific branch.

This issue is primarily about evaluator coverage and maintainability rather than requesting full semantic support for all of these opcodes immediately. Having explicit `case` labels for these opcodes would make the evaluator easier to audit and would make the current support status clearer.

For example, `DW_OP_call2` and `DW_OP_call4` already have explicit branches that return an `unimplemented opcode ...` error. A similar pattern for the opcodes below would make it clearer that they are intentionally unsupported during evaluation, rather than being omitted accidentally.

## Affected DWARF Opcodes

The following opcodes appear to be handled by decode-side logic but not explicitly listed in the main evaluator switch:

* `DW_OP_const_type`
* `DW_OP_reinterpret`
* `DW_OP_regval_type`
* `DW_OP_deref_type`
* `DW_OP_xderef_type`
* `DW_OP_constx`
* `DW_OP_call_ref`
* `DW_OP_GNU_implicit_pointer`

Some of these opcodes can appear in real GCC-generated debug information, so making their evaluator behavior explicit has practical value.

`DW_OP_GNU_implicit_pointer` is slightly different from the other entries in this list. LLDB already has an explicit evaluator branch for the standard spelling `DW_OP_implicit_pointer`, so this is not just another missing-case hole. In that specific pair, the GNU spelling is treated as if it were unsupported, even though the equivalent standard spelling already has dedicated evaluator handling in the same file.

## Suggested Direction

One possible improvement would be to add explicit `case` labels for these opcodes in `DWARFExpression::Evaluate`.

If full support is not intended at this time, these cases could initially return opcode-specific `unimplemented opcode ...` errors, following the existing pattern used by `DW_OP_call2` and `DW_OP_call4`.

This would make the evaluator's behavior easier to understand and help future maintenance by clearly distinguishing intentionally unsupported opcodes from opcodes that may have been overlooked.

Start in lldb/source/Expression/DWARFExpression.cpp and read DWARFExpression::Evaluate, especially the existing DW_OP_call2 and DW_OP_call4 branches and the decode-side handling described in the issue. Trace the listed opcodes through the evaluator switch; done means their behavior is explicit and consistently reports intentional lack of support where full evaluation is not provided.

Written by the indexing model from the issue text.