Static constructors for built-in providers.

Add config.h defines for each built provider and if that provider is built as a DSO. Make
changes to init functions to match: remove ctor on fi_ini and call explicitly, only have the
ctor attribute defined on the providers if built as DSO, explicitly call built-in providers
and declare their init defs in fi.h

This should work for all our supported build configurations, and should not work for static-build plus dl-loading built-in providers (which I assume is unsupported).

Tested with dso providers and built-in, needs testing for static linking and other more providers. @sayantansur @jsquyres

I can centralize a lot of the sprinkled ifdefs in one header (for example: include/provider.h) that is included by fabric.c and the various providers if that is wanted.

fixes #293 

Signed-off-by: pmmccorm <patrick.m.mccormick@intel.com>
That this is sufficient -- it's racy when if are multiple threads that can call fi_getinfo().

According to http://ofiwg.github.io/libfabric/master/man/fi_getinfo.3.html:

> Multiple threads may call fi_getinfo “simultaneously, without any requirement for serialization.”

Before I got crazy with SC prep, I submitted a different patch that uses a mutex to ensure that it's not possible for any caller to pass a certain point until the very first caller had invoked all the provider constructors.

Ah, here it is: #297.  I think there's 2 points of contention on #297:

1. We seem to disagree on who should call the constructors.  I think it should be infrastructure.  You guys think it's ok to hard-code the names.  My point: "simple" is not the enemy of "infrastructure".  Indeed, I think it should be simple for provider authors -- perhaps at the expense of a little infrastructure.
1. I had thread protections in the init sequence for fi_getinfo().

At a minimum, I think the 2nd part is needed here -- it *must* be thread safe.