Remove deadlock in ot_terminate()

The method acquires a lock on the static mutex `the_Mutex`.

It then calls itself recursively by re-throwing the exception and hangs because
it has already acquired the lock.

This freezes the process on my Linux system, but it should freeze on other
systems as well.

Unclear purpose, removed.

The mutex used in the signal handler code has the same issue.
Fix misleading comment.

Signal handlers are defined further down.

If `OT_SIGNAL_HANDLER` is defined, the initialization routine in
`OT_API::InitOTApp()` calls `OTLog::SetupSignalHandler()`.
Check for exception before re-throw, fix comments.

Recursion check originates here and is unnecessary now:
http://efesx.com/2010/03/21/catching-uncaught-exceptions-within-terminate/

Also call std::abort() instead of abort().
Use print_stacktrace() instead of inline code

The `print_stacktrace()` function defined in `core/util/stacktrace.h`
essentially does the same thing and also does the platform-specific stuff. It
should be used in a few other places in this file as well.

This still prints stacktrace twice in OT_FAIL* and OT_ASSERT* macros (and three
times if we enable signal handlers).

The `print_stacktrace()` call from OTLog::logAssert could be skipped if we know
for sure that `ot_terminate()` is our handler for `std::terminate()`. Maybe
introduce a flag `OT_ASSERT_PRINT_STACKTRACE` to control that.
Merge pull request #209 from OttoAllmendinger/fix-terminate

Fix deadlock in ot_terminate()
OTServerConnection: Remove noop branch

Once upon a time this had actual code, but it was commented out without
explanation and later removed:

https://github.com/Open-Transactions/Open-Transactions/commit/228d65aed9d9a4b3d61a7ad14afd3e6750293760#diff-5b6e4090c4226209dacc925f3321f3a4R792

Shout out to @haarts who discovered it
Merge pull request #222 from OttoAllmendinger/fix-send-noop

OTServerConnection: Remove noop branch