Clean up dl-open features:

Add --with-dlopen=[yes,no] option to compile without loadable provider support.
Selecting no also disables the check for -ldl.

Add --with-extdir option to specify custom loadable provider dir.
Default is $libdir/libfabric.

Rename FI_EXTPATH to FI_EXTDIR for consistency with variable names and configure options.

Silently ignore extdir not found when loading instead of printing error to stderr.

Remove unused includes in fabric.c

Re-include common.c and enosys.c in dl-loadable providers, these are needed.
Thinking about this a bit more...

If these functions are intended for providers only, I am leaning towards option 1 (i.e., libfabric_provider_helpers.la).  We do a very similar thing in Open MPI (for code that is shared among multiple plugins) -- here's why:

1. If providers that use these common functions LIBADD libfabric_provider_helpers.la, then the linker will do the Right Thing: it will load *one* copy of all the referenced .o files from libfabric.so when DL providers are dlopened at run-time, and simply reference that *one* copy of each function from each provider who uses it.
1. Similarly, if all providers are statically linked into libfabric (and we create libfabric_provider_helpers.a), the linker will again do the Right Thing and only have *one* copy of each symbol, and each provider will use it.
1. I'm also pretty sure that if there's DL provider foo and static provider bar that both use common function fi_yow, and libfabric_provider_helpers.so is available, then the linker will do the Right Thing and only have *one* copy of fi_yow in the target process. 

This wiki page helps explain how I got to this conclusion (from Open MPI): https://github.com/open-mpi/ompi/wiki/Linkers.

Mixing dynamic and static linking makes things kinda complicated and can seriously hurt your brain.