gstinfo: Improve usage of libdw for backtraces

When getting backtraces, we were always creating a new Dwfl context and then discarding it. The problem with that is that it resulted in having to re-scan a lot of information for every single backtrace.

In order to fix that issue, use a global on-demand Dwfl context and use it with a lock.

Furthermore, we were scanning the mappings of the process (dwfl_linux_proc_report) for every single step in the backtrace, and that function is horrendously expensive (does sscanf on /proc/PID/maps ...). While there is a possibility that new mappings might be available (new plugins being loaded for example), we can limit ourselves to just do it once per backtrace.

These two modifications speed up the elements_leaks unit test (which traces all pads with full backtraces) by a factor of 6.

Partially fixes #567 (closed)