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.
If that's the intent, I see a few options:

1. These functions should be in a single, standalone library (e.g., libfabric_provider_helpers.la)
1. These functions should be `static` at a minimum (so that there's never the possibility of 2 identical public symbols in an executable), and possibly `inline` (properly marked as "always inline" so that no linker symbol is generated).  E.g., it will cause a run-time linker error if someone implements their own fi_no_bind() in their own source code, but then *also* uses the common enosys.c.  Bad Things can happen.
1. Don't provide these at all.  It's just syntactic sugar for 1-line functions.
1. Require that providers actually copy these source files to their own provider tree, and either make them static (so as not to conflict with anyone else's copies) or otherwise change the symbol names (e.g., prefix them with their own provider name).

Whatever happens, these functions should be in clearly marked files/comments that indicate that they are *not* part of libfabric and are intended as a convenience to provider implementors.  I say this because the intent you have described here really wasn't clear to me when I read the code (even if the name "common.c" was meant to imply this -- "common" has different meanings/implications for different developers...).