PR#5899: user-friendly representation of backtraces

Joint work with Jacques-Henri Jourdan, this is the latest patchset to improve backtrace collection and inspection. A previous version of this patch was submitted by Jacques-Henri on mantis ([PR#5899](http://caml.inria.fr/mantis/view.php?id=5899)); the new version has a few change suggestions, and we use the fancy github PR process in the hope of getting more eyeballs on the patch.

Main changes:

> - `raw_backtrace` is no longer an abstract type, but rather an
>   `raw_backtrace_slot array`, where `raw_backtrace_slot` is a new
>   abstract type. `raw_backtrace_slot` elements are hashable and
>   comparable. At runtime, values of this type contain either
>   a bytecode pointer or a frame_descr pointer. In order to prevent the
>   GC from walking through this pointer, the low-order bit is set to
>   1 when stored in the array.
> 
> - The old `loc_info` type is know public, renamed into `backtrace_slot`:
> 
>       type backtrace_slot =
>         | Known_location of bool   (* is_raise *)
>                           * string (* filename *)
>                           * int    (* line number *)
>                           * int    (* start char *)
>                           * int    (* end char *)
>         | Unknown_location of bool (*is_raise*)
> 
> - new primitive :
> 
>     val convert_raw_backtrace_slot: raw_backtrace_slot -> backtrace_slot
> 
>   Rather than returning an option, it raises Failure when it is not
>   possible to get the debugging information. It seems more idiomatic,
>   especially because the exceptional case cannot appear only for a part
>   of the executable.
> 
> - the caml_convert_raw_backtrace primitive is removed; it is more
>   difficult to implement in the C side because of the new exception
>   interface described above.
> 
> - In the bytecode runtime, the events are no longer deserialized once
>   for each conversion, but once and for all at the first conversion,
>   and stored in a global array (*outside* the OCaml heap), sorted by
>   program counter value. I believe this information should not take
>   much memory in practice (it uses the same order of magnitude memory
>   as the bytecode executable). It also makes location lookup much more
>   efficient, as a dichomoty is used instead of linear search as
>   previously.