Rework processing queue threading

Rework processing queue threading

This patch is a large rework to simplify the processing portion
of corewatcher.  The processing queue is represented now simply
in the filesystem by the presence of *.to_process files, or
*.processed files which lack an associated summary report *.txt file.
The scan_processed_folder() function now is a thread which sleeps on a
condition variable, which in turn is set by the event threads.  Previously
that function did an opendir() on processed_folder and spawned a thread
per found corefile to process the cores, with associated complexity in
data structures and locking.  Now that function is the main loop of the
single processing thread.

- removed remaining global state in core_status struct, processing
  queue array of filenames, simplified locking, simplified state machine,
  some function renames for clarity, updated README
- removed spawning of threads per core to process, adding instead a single
  long lived thread which sleeps on a condition variable set in
  queue_backtrace() and the timer event loop
- if a summary crash report has been created already, don't re-run gdb,
  just read in the report and try to submit it
- audited object lifetimes, added some strdup()'s, free()'s, valgrind now
  shows no leaks in corewatcher code (NOTE: a valgrind warning for
  uninitialized bytes is triggered from corewatcher's submission path
  which originates in glibc 2.16.0 resolv/res_send.c, a patch has been
  submitted to the glibc project)
- added lots of additional logging, especially in error paths
- the gdb mutex is removed as it effectively became a NOOP as it would
  now be used only in one call chain that is never called in parallel

The timer thread is still needed as network issues can prevent submission.
A network event thread could now be added to attempt submission when
any network becomes present and also to attempt reprocessing when
high-bandwidth network becomes present to improve report quality in the
case of a debuginfo daemon then being able to dynamically pull in helpful
data for gdb.  Even then the timer thread would still be needed to handle
the cases of the crashdb server being down or intermediate network issues
preventing submission, situations which aren't trivially distinguished
at the client side in order to spawn an event upon their resolution.

Signed-off-by: Tim Pepper <timothy.c.pepper@linux.intel.com>