ast_coredumper: Increase reliability

ast_coredumper: Increase reliability

Instead of searching for the asterisk binary and the modules in the
filesystem, we now get their locations, along with libdir, from
the coredump itself...

For the binary, we can use `gdb -c <coredump> ... "info proc exe"`.
gdb can print this even without having the executable and symbols.

Once we have the binary, we can get the location of the modules with
`gdb ... "print ast_config_AST_MODULE_DIR`

If there was no result then either it's not an asterisk coredump
or there were no symbols loaded.  Either way, it's not usable.

For libdir, we now run "strings" on the note0 section of the
coredump (which has the shared library -> memory address xref) and
search for "libasteriskssl|libasteriskpj", then take the dirname.

Since we're now getting everything from the coredump, it has to be
correct as long as we're not crossing namespace boundaries like
running asterisk in a docker container but trying to run
ast_coredumper from the host using a shared file system (which you
shouldn't be doing).

There is still a case for using --asterisk-bin and/or --libdir: If
you've updated asterisk since the coredump was taken, the binary,
libraries and modules won't match the coredump which will render it
useless.  If you can restore or rebuild the original files that
match the coredump and place them in a temporary directory, you can
use --asterisk-bin, --libdir, and a new --moddir option to point to
them and they'll be correctly captured in a tarball created
with --tarball-coredumps.  If you also use --tarball-config, you can
use a new --etcdir option to point to what normally would be the
/etc/asterisk directory.

Also addressed many "shellcheck" findings.

Resolves: #445
(cherry picked from commit 26c98bc68b9b12cc577e68ce66435b8dfc617efe)