TODO: Write instruction_addr_heuristics RFC

[Swatinem]

We currently have some heuristics in symbolicator (and some even in SDKs) that adjust stack frames.

The intention is that depending on the platform, a call / bl instruction will always push the following return address on the stack or into the lr register.
In symbolicator, we then go to the previous instruction which should land us back at the call / bl.

This heuristic is not applied to the very first frame, as we assume the first frame points to the actual crashing instruction (eg a mov that tries to access invalid memory)

However we don’t know at processing time if the first address is a crashing instruction or a return address that needs to be adjusted. In particular if SDKs truncate the top of the stack trace to throw away implementation details of the stack walking implementation itself.

This also does not work for profiling, which will index/deduplicate all the stack frames into a single large list, and the notion of what is the "top" frame is completely lost.

@mitsuhiko proposed to introduce a new instruction_addr_heuristics property on stack traces with the following options:

• all always use the previous instruction
• none do not adjust the instructions at all
• all_but_first adjust all but the first frame
• magic (current behavior) try to infer if we need adjustment for the first frame or not

[Swatinem]

RFC is here: #43
I also chose to slightly rename the proposed attr and values