frametypes should also describe registers and callee-save stack slots

[stephenrkell]

We currently postprocess local variables' DWARF in the frametypes tool, which computes a collection of stack frame layouts for each function. We can think of these as stack maps, each covering a particular range of program counters. However, they currently describe only things that are (1) local variables and (2) literally on the stack, i.e. in memory.

Internally, frametypes is building a map from stack offsets to the DWARF entry (DIE) that resides at that offset.

set<pair< 
		Dwarf_Signed, // frame offset
		iterator_df< with_dynamic_location_die >
	>,
	compare_first_signed_second_offset 
>

(and aggregating these in a boost::icl::interval_map, since each is valid over a particular range of addresses).

There are two small generalisations of this tool that would give us a more complete view of the stack and registers.

1. Instead of just a frame offset (Dwarf_Signed), allow the 'where' to be a register, and include register-allocated local variables. (Tricky: what to do when a variable is split between a register and memory? This does happen, and can be described by DW_OP_piece.)
2. Instead of just local variables, allow the 'what' to be "our saved copy of the caller's [some callee-save register]". The DWARF .debug_info section does not tell us this, but the .debug_frame or .eh_frame information does (see also Stack walking should use eh_elfs from frdwarf #83). This is important because the saved value might be a pointer -- though we'd have to look at the caller's type information to know that, since to the callee that does the saving it is just an opaque word-sized value.

This might also tie in with rethinking how we represent stack frames at the uniqtype level (#85).

If we had this information, we could get closer to precise stack-scanning for garbage collection (no doubt some gaps and other ambiguities would still remain, but we could measure the reduction!), other applications that can require us to rewrite pointers (stack reconstruction for dynamic software update, on-stack replacement, etc), and general debug-time features ("what is this stack slot representing?" / dumping memory in a more abstract or more explained form).

[stephenrkell]

I have subsumed this into #85.