Attempt to make the configuration of ipv4 and ipv6 interfaces more
sensible with regard to implementations by:

* change the "network" key, defining which interface a V1_LWT.NETIF
  should attempt to attach to, to "interface".
* changing V1_LWT.IPV4's prefix type to Ipaddr.V4.Prefix.t,
  addressing a longstanding FIXME.  Ipaddr.V4.Prefix.t defines a
  network, not just a netmask, so change this name and provide the
  expected converters.
* removing the ip_config type, which was a GADT over ipv4 and ipv6.
  This forced ipv4 and ipv6 configurations to assume that the same
  number of addresses, netmasks, or gateways were reasonable, which is
  not the case; see #557
* creating an ipv6_config record type (and associated Mirage_key
  functions) that stores lists of addresses, netmasks, and gateways
* creating an ipv4_config record type (and associated Mirage_key
  functions) that stores only a single address, netmask, and gateway
* exposing both ipv4_config and ipv6_config in V1_LWT
* removing the netmask and gateway getter/setter functions from the
  module type IP.  ipv4 will expect to get this information either via a
  DHCP lease or at connect time via keys, and ipv6 largely determines it
  dynamically.
* removing direct_stack_config, as the stack should receive a configured
  ipv4 argument (whether via DHCP or static configuration isn't the
  stack's concern)
* putting the default values for statically-configured ipv4 modules into
  mirage_key, where they can be nicely exposed to the user via help.
* removing direct_stackv4_with_default_ip, direct_stackv4_with_dhcp, and
  direct_stackv4_with_static_ipv4.  Instead, let functoria figure out
  which implementation should be used based on the keys supplied and
  reasonable defaults via the function direct_stackv4, which requires
  more arguments -- network, ethernet, arpv4, and ipv4, rather than just
  network.
* requiring network, ethernet, and arp implementations as arguments to
  create_ipv4 instead of just a network implementaiton.  Doing so means
  that an ipv4 implementation can be configured and then handed off to
  stackv4.

Create V1_LWT.DHCP_CLIENT, which defines only type `t` and exposes it to
be a V1_LWT.ipv4_config Lwt_stream.t .  The intent is that users watch
the stream for updates on lease information.

Use tcpip's Dhcp_ipv4 module to configure an ipv4 impl with dhcp.
Disambiguate between the two ipv4 modules by calling the static one
ipv4_keyed_conf (because it's configured through the key system) instead
of ipv4_conf .  generic_stack will now choose between a keyed
configuration and a DHCP-based one depending on the value of the `dhcp`
key.

…_config record

Keys are provided by the ip device.

improvements to ipv4 configuration