configury: move provider-specific configury into separate .m4 files

Allow providers to have their own configure.m4 file that is
m4_include'd in the top-level configure.ac file.  This helps keeps
provider-specific logic down in the respective prov/[foo] directories.

Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
verbs: configury updates

1. Use numeric values for some shell variables.  This lets you use -eq
and -ne test operators, and basically provides for a) (slightly)
better error checking, and b) using the same values in
AC_DEFINE_UNQUOTED.
2. Divorce the concept of whether the user asked for verbs from
whether it can actually be compiled.
3. If the user asked for verbs and it can't be compiled, print a
nice explanitory message before erroring out.
4. Also check for header files; it's a common error for users to have
libraries installed but not the relevant foo-devel packages installed.
5. Always output an AC_MSG_NOTICE in the configure output telling the
user a) whether this provider will be built, and if so, b) whether the
provider will be built statically or as a DSO

Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
sockets: configury updates

Quite similar previous commit in the verbs provider, but for the
sockets provider:

* use numeric shell variables
* separate check of whether provider can be built from whether user asked for it
* print appropriate notice/error messages

Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
psm: configury updates

Quite similar previous commit in the verbs provider, but for the psm
provider:

* use numeric shell variables
* separate check of whether provider can be built from whether user
* asked for it
* print appropriate notice/error messages

Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
Merge pull request #132 from jsquyres/topic/configury-suggestions

Configury updates for verbs, sockets, psm