Build: Static constructors for built-in providers

Change how internal and external providers are built to fix static
build issues.  External providers are now required to export a
well known API that is invoked by the libfabric framework.  This
replaces the fi_register call that libfabric exported.

Update the build configuration to better handle building in-tree
providers as separate DLLs (for testing purposes).  When building
an in-tree provider as a separate DLL, it now needs to export
the required fi_prov_ini function.

Signed-off-by: pmmccorm <patrick.m.mccormick@intel.com>
Signed-off-by: Sean Hefty <sean.hefty@intel.com>

Replaces PR #335
Is there ever a use case to have two different versions of libfabric installed (obviously, in different locations), but with both versions loading DSOs from the same location?  E.g.:

* libfabric vA.B installed into /usr
* libfabric VC.D installed into /opt/SOME_PRODUCT/embedded_libfabric
* both look for libfabric DSOs in /usr/lib/libfabric

Or perhaps a more likely scenario would be that SOME_PRODUCT has libfabric vA.C embedded (i.e., only a minor rev difference between the system-installed version -- e.g., to work around some known bugs in vA.B, or somesuch).

If such scenarios are meaningless, then I agree -- always printing out version mismatch error messages is fine.  But if these kinds of scenario are possibilities, then version mismatch error messages should probably be output conditionally.