opal_lifo: fix potential race condition when using 128-bit atomics

On x86_64 reading a 128-bit value requires multiple instructions.
Under some conditions if the counted pointer counter is read before
the item pointer the fifo can be left in an inconsistent state. This
commit forces the read of the counter to always be read first.

The fifo does not appear to suffer from the same race.
class tests: change from opal_init() to opal_init_util()
class tests: re-enable a bunch of tests

Many of these tests were failing due to opal_init() failing in some
cases (because the opal shmem framework needs installed components, so
"make distcheck" would fail these tests because the opal shmem
components were not installed).  However, all of these tests seem to
be fine with opal_init_util() -- so let's re-enable these tests.
Whitespace cleanup only; no code changes
test/class: update class tests to also use opal_finalize_util
.gitignore: ignore executes for new tests
help messages: fix obvious typos
With PGI compile we need stdarg.h for va_list define
libfabric: don't use __thread

There's no real reason that this routine should use thread local
storage.  Plus, __thread appears to be a GCC extension.
libfabric psm: fix (void*) dereference

Committed upstream to libfabric as well.
Change logging function name from log to logfn.  Fixes issue with PGI compile
btl/vader: fix compile on SGI UV
Don't install the Java shmem tools if we aren't building Java support. Thanks to Paul Hargrove for noticing.
Okay, okay - use the oshmem word here
mpool/udreg: minor comment improvement
Two cleanups required for transfer to 1.8.4:

* Use %d format for the topo signature as some systems apparently have problems with %u
* Use correct variable in show_help message
Correct some issues with variables used before being set
It looks like the guess_len function in our local printf.c has some questionable code in it. Now that we are checking in configure for vsnprintf, take advantage of that check to use the far simpler method if it is available. Given that we no longer support such ancient systems where this might not be available, one suspects the other questionable code may no longer be required - but set that aside for another day.
Fix the race condition in endpoint connection initialization. The race
was quite subtle, and only happened on the process with the smallest
guid (as this process will tear down the connection created locally and
replace it with the result of accept). If multiple threads are active in
the system, the deadlock occurs during the recv event deletion as one
thread will hold the recv event lock of the endpoint and try to access
the TCP event base lock, while the other thread will hold the TCP event
base lock while trying to access the recv event lock (in case data is
available on the socket).

The proposed solution let the event callback fail to process the data,
preventing the deadlock and allowing the other thread to always complete
it's job. As the event is not execute the same triggered will trigger
again at the next opportunity, so this solution introduce a minimal
delay in the connection establishement.
Add the necessary infrastructure to allow the dumping of all TCP
informations related to an endpoint (status and all pending fragments).
Do some minor space cleanup.