read: add Evaluation::value_result

[philipc]

DWARF expressions can be used to either compute a value or a location description, depending on context.

Currently a value computation will result in a location description that contains one Piece whose location is set to Location::Address, and this address is the computed value.

Evaluation::value_result makes it easier to obtain this value, supports results that are typed values, and checks there were no operations that only valid for location descriptions.

Closes #675

[philipc]

@khuey You've probably used the DWARF expression support the most. Do you think this change would be useful?

[khuey]

I'm not really convinced this is worth the complexity. What does this solve besides the user's issue in #675? Is the typed value stuff separable from this?

Another issue that the spec does not always match what happens in practice. DW_AT_vtable_elem_location, for example, is treated as a value (at least as of clang 16), not a location, despite what the spec claims. There might be others (especially among the weird Fortran attributes).

[philipc]

I'll defer to your judgement. If this hasn't been a problem for you then there's no point changing it.

What does this solve besides the user's issue in #675?

It encodes some more knowledge in gimli, without requiring every user to duplicate that knowledge.

Is the typed value stuff separable from this?

We could probably add the pub fn value_result(&self) -> Value without needing to add ExpressionKind.

Another issue that the spec does not always match what happens in practice.

We would change it to do whatever happens in practice then.

[philipc]

Is the typed value stuff separable from this?

This is trivial, so I've changed the PR to just do that.