opal_lifo: fix one more potential issue with the new 128-bit lifo atomics

It is possible the compiler can reorder the read of the head item and
the head itself. This could lead to a situation where the item
returned was not really the head item.
Add support for CUDA Unified memory.  Basically, add a new flag and disable some
optimizations when that flag is detected.  Lightly reviewed by bosilca.
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.