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>
Using well-known symbol names is not uncommon -- it's very common in dlopen code to dlsym to look for specific symbols.

Having infrastructure generate appropriate code is a Good Thing, especially when that code a) is generic/easily templated, b) can vary depending on build conditions, and c) reduces the number of touch-points for developers to maintain (e.g., especially in plugin types of scenarios).  It also reduces human error, because humans don't have to generate (and maintain) that rote code.