Pull over Jeff's original patch. Update it per George's comments: since opal_using_threads is always false if thread-multiple hasn't been enabled, there is no reason to include checks for it in that condition. So restore the #if statements in opal/threads/mutex.h to regain the remaining missing performance. Also, restore the thread debugging code as there is no reason to exclude it as it only builds in debug environments
btl/tcp: fix hang when using multiple threads

There was a hang in the tcp btl that caused a hold-and-wait scenario
when processing libevent events. The problem was due to one event holding
the event lock while waiting for the endpoint lock while another thread
was holding the endpoint lock while waiting for the event lock. The fix
is simple: drop the endpoint lock before trying to delete a libevent
event. The fix was tested with osu_latency_mt.
Correctly propagate the requested level of thread support during the
component init calls.

Conflicts:
	ompi/runtime/ompi_mpi_init.c
Pull across open-mpi/ompi@343071498965a8f73d5f2b0c27a7ef404caf286c
Merge branch 'cmr/thread-multiple' of https://github.com/rhc54/ompi-release into cmr/fix-thread-multiple

Conflicts:
	opal/runtime/opal_progress.c
Merge pull request #120 from rhc54/cmr/fix-thread-multiple

This will be the official pull request to fix thread-multiple on 1.8.4