propolis-server API types can have different definitions depending on feature flags

#231 makes the InstanceSpec type and its components part of the propolis-server API. Some of InstanceSpec's components are conditionally compiled based on the value of the falcon feature flag, so enabling/disabling the flag changes propolis-server's OpenAPI specification. This can create some friction when working with types generated from the OpenAPI spec (if the spec's falcon configuration differs from the builder's configuration). When fixed, #227 will create a similar problem for PCI bridges.

We can eliminate this toil in a couple of ways:

1. Create/maintain separate OpenAPI descriptions to be used when the falcon feature is enabled (or when other features are enabled/disabled)
2. Maintain a single definition of the InstanceSpec types, but make propolis-server recognize and honor the Falcon-only elements only when the feature is enabled (and similarly honor other options only when their corresponding features are enabled)

Start by reviewing issue #231 and the propolis-server API/OpenAPI generation path described here. Compare the specification with Falcon enabled and disabled, and consider the two approaches outlined in the issue. Done means feature configuration no longer causes incompatible API type definitions, including the future PCI bridge case from #227.