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.
> The fact that you're providing common code for providers to use means that
> you are providing APIs that need to be maintained -- regardless of whether
> they're in libfabric or not. So why not put them in libfabric? Then all of
> these issues go away (and if dlopen is failing when the symbols are
> compiled into libfabric, then we're doing something wrong with the dlopen
> -- it should be a fixable problem).

These are some helper functions that in-tree providers can take advantage of.  An external provider is on their own.  That doesn't mean that we want the library to actually export these.  Here's a sample:

int fi_no_bind(struct fid *fid, struct fid *bfid, uint64_t flags)
{
	return -FI_ENOSYS;
}
int fi_no_sync(struct fid *fid, uint64_t flags, void *context)
{
	return -FI_ENOSYS;
}

I.e. for every interface defined by libfabric, we provide an ENOSYS implementation.  We don't want to export all 100+ of these.  By keeping these internal, we can freely change them, since all users are in-tree.  As soon as they're exported, changes to those APIs become far more difficult to handle.  In-tree providers get the benefit of using these.  Out of tree providers are on their own.