flux-module, broker, libflux: rework module API

Services implementing 'module extensions' will implement
insmod, rmmod, lsmod operations defined in RFC 5.  Provide an API
for calling these operations and utility functions to help services
implementing them.

flux-module is now a general purpose tool for managing modules
within any service.  modctl functionality is temporarily out;
it will be restored with the commit reimplementing modctl on the
new interfaces.

The broker and flux-module are updated to use the new API.

Testing: unit tests for RFC 5 protocol encode/decode are added.
One place in test where we loaded modules on two ranks using modctl
(t/t0002-request.t) was modified to use the simpler flux-module
interface directed at successive ranks.
modctl: redesign based on libmrpc

Redesigned modctl can operate on a hierarchy of dynamically loaded
modules (e.g. comms modules, modules that load modules, etc).
In addition the new modctl:

Fixes #57 flux-module list works around lack of sync with usleep
Fixes #56 flux-module cannot unload a module it did not load
Fixes #94 Request flux module load rank option

modctl speaks RFC 5 to services that implement module extensions.
It implements an "mrpc" based protocol that executes module operations
in parallel on a user-specified nodeset.  The modctl "API" is no
longer exported via libflux-core and is kept private between modctl
and flux-module.

The use of mrpc greatly simplifies the design compared to the previous
modctl.  However, the new design has following caveats:
- does not yet implement scalable .so loading through the KVS
- there is no "smart" data reduction of RFC 5 responses,
  except what libmrpc achieves by KVS object squashing
- some scenarios exist where modctl or the flux-module may hang in
  a kvs_fence(), e.g. node failure or flux-module abort at just he
  wrong place

Some of these scalability and resiliency issues can be solved more
generally through changes to mrpc.  This is likey preferable to building
a more complex, standalone modctl system with these characteristics.
broker: destroy inproc://dq-req on module unload

We were waiting around for these sockets to be cleaned up when the
context was destroyed, but now that modules are dynamic, that's a
resource leak.

In addition, while testing modctl, occasionally we would see a
fatal bind failure:

  cmbd: zsocket_bind: inproc://dq-resp-0x10059c0: Address already in use

Possibly the "unique" value based on plugin pointer value was
getting reused.  In any case, closing sockets seems to have fixed it.
test: add tests for module management

t/t0003-module.t exercises the local module management operations,
including a comms module and a module loaded by that comms module.

t/10002-modctl.t exercises the distributed module mgmt operations.
Same as above but using modctl to make it happen in parallel.
doc: add man page for flux-module