Fix CUDA registration where we run out of memory being allocated.
This fixes the oshmem build bug identified by Orion Poplawski where shmem 
wrapper-data incorrectly adds @OMPI_WRAPPER_EXTRA_LIBS@. This fixes #4796 and should be
added to: 

cmr=v1.8.2:reviewer=jsquyres
shmem: include the rest of the patch -- update comments

Update the comments to be correct.

cmr=v1.8.2:ticket=#4808
Create new error message so we can better pinpoint where an error occurs.
Changes to VT/OTF:
Ensure that target directories exists before creating symlinks.

cmr=v1.8.2:reviewer=jsquyres

Thanks Jeff to step up as an reviewer.
usnic: check connectivity on first communication to a peer

Previously, we were only checking connectivity upon first ''send'' to
a peer.  But this ignores the case where the first communication to a
peer is actually an ACK -- i.e., we successfully received something
from the peer and we need to send an ACK back.  So we need to verify
that the ACK will actually get there.

Specifically, certain asymmetric routing cases can lead to a hang if
we don't check the connectivity in both directions.  E.g., if the
sender is able to get traffic to the receiver, but the receiver is
unable to get traffic back to the sender because it made a different
routing decision than the sender.

In this case, the connectivity checker from the sender could succeed
(because the connectivity checker will ACK along the same path in
which the ping was received), but sending a BTL ACK could fail
(because the BTL ACK will be sent back along the path chosen by the
graph algorithm, which, in an erroneous asymmetric routing scenario,
may be different/wrong).

Hence, we want to trigger the connectivity checker at the first
communication from A->B, which may either be a BTL send or an ACK.

Reviewed by Dave Goodell.

cmr=v1.8.2:reviewer=ompi-rm1.8
Now that we are using the radix routed module, teach it how to behave nicely with singletons
AUTHORS: Add bwesarg
usnic: minor cleanup / consolidation

CMR'ing just to (try to) keep the differences between trunk and v1.8
branch (somewhat) small.

Reviewed by Dave Goodell

cmr=v1.8.3:reviewer=ompi-rm1.8
usnic: revert r32315 because the BTL move to opal is ongoing

Let's not make the move to OPAL any harder than it has to be; this
commit can wait until after the BTL move.
George did the work and deserves all the credit for it. Ralph did the merge, and deserves whatever blame results from errors in it :-)

WHAT:    Open our low-level communication infrastructure by moving all necessary components (btl/rcache/allocator/mpool) down in OPAL

All the components required for inter-process communications are currently deeply integrated in the OMPI layer. Several groups/institutions have express interest in having a more generic communication infrastructure, without all the OMPI layer dependencies.  This communication layer should be made available at a different software level, available to all layers in the Open MPI software stack. As an example, our ORTE layer could replace the current OOB and instead use the BTL directly, gaining access to more reactive network interfaces than TCP.  Similarly, external software libraries could take advantage of our highly optimized AM (active message) communication layer for their own purpose.  UTK with support from Sandia, developped a version of Open MPI where the entire communication infrastucture has been moved down to OPAL (btl/rcache/allocator/mpool). Most of the moved components have been updated to match the new schema, with few exceptions (mainly BTLs where I have no way of compiling/testing them). Thus, the completion of this RFC is tied to being able to completing this move for all BTLs. For this we need help from the rest of the Open MPI community, especially those supporting some of the BTLs.  A non-exhaustive list of BTLs that qualify here is: mx, portals4, scif, udapl, ugni, usnic.
Add missing rename of file
Turn off the ompi_rb_tree test for now
Update git/hg ignore files
Correctly dereference the thread object
Rename the help file.
Rename all the win32 files to use the correct layer name.
Move some of the ompi_process_info down in OPAL.
Use opal_process_info whenever possible. Some other minor cleanups.
Cleanup (not tested).