[RFE] Feature parity with MetalSmith

[Dmitry Tantsur]

# Strict input validation.

While Ironic allows a user to set anything in instance_info, only reporting an
error on an explicit validate call or when a deployment is requested,
metalsmith does not allow free-form input.

Potential solution: Deployment API with a strict schema (even if instance_info
is still the backend).

# Convenient support for capabilities and custom filters

MetalSmith can create allocations based on not only the standard fields
(resource class, traits, etc), but also the classic capabilities. Python API
also features custom predicates.

Possible solutions:

* I haven't added their support to the Allocation API because we all hoped that
  capabilities would be gone soon. Well, there are no signs of that happening,
  so maybe we should expand the Allocation API.

* I'm not sure how useful the custom predicates are, but we could add them
  to ironicclient/openstacksdk.

# Native support for some configdrive fields

Generic features:

* SSH public keys
* Host name

Cloud-Init features:

* UserData format
* Creating users

The current Ironic API can build a configdrive from JSON input, but doing these
basic operations still requires diving into cloud-init documentation.

# Deployments as first class objects

MetalSmith operates on deployments, which are virtual objects combining nodes
and allocations. It can list deployments, show their details, deprovision.
Host name is used as a deployment name.

Solution: Deployment API was drafted specifically for this purpose.

# Direct integration with Neutron

While Ironic only operates on abstract VIF UUID, MetalSmith knows about ports,
networks and subnets, allowing similar user experience to Nova ("give me a port
on this subnet", etc). It can create ports and then store their ID in the
node's extra for subsequent removal.

Solution: Do we need first-class Neutron support? Would it clash with Nova too
much?

# Generating network data from Neutron information

Similarly to Nova, MetalSmith can provide a network data from ports attached to
a node. It supports IP addresses, IPv6 parameters, MTU settings, routes and
DNS.

Solution: Regardless of the previous point, we do get port UUIDs as VIF IDs,
so it's possible to populate network data. Maybe we should allow requesting it
explicitly, e.g. with `{"configdrive": {"network_data": "auto"}}`?