Working csharp wrapper, needs further testing/refinement
Merge pull request #203 from BlueWall/develop

Csharp wrapper
Updates build instructions.

Adds ZMQ.
Adds ZeroMQ to Fedora install instructions.
Adds ZeroMQ to openSUSE install instructions.
Merge pull request #211 from haarts/develop

Updates build instructions.
Fixed header guards for server library.
Merge pull request #219 from murrekatt/develop

Fixed header guards for server library.
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()