Blueprints need to to know which IP Pools to draw from for services

This issue is more broad than some of the related ones, since I don't know much about the blueprint system. I'll flesh it out as I learn more and talk with other folks closer to that part of Omicron.

Right now, it appears that the blueprint system uses the ExternalIpAllocator type to dole out IP addresses for Omicron zones that need external connectivity. That is populated with a single Vec<IpRange>, representing a homogeneous set of IP Ranges that it can collect from. These are collected from the database when needed and passed as the PlanningInput to the builder.

The issue is that this assumes all the service IP Pool Ranges are fungible. When creating a new blueprint, the resource allocator chains these ranges together, consuming them in order until it has all the addresses it needs for the zones it's going to deploy.

In the long run, operators need a way to control which pools and ranges are used for which services. The simplest example, which spawned all the related work, is a customer running both IPv4 and IPv6 networks. They need to be able to ensure that, say, Nexus listens on both an IPv4 and IPv6 address, so that the public API is available to the various parts of their network.

It seems like the planning input could contain information about the operator's intent here, about the IP Pools from which each relevant service should draw an IP to listen on.

Start by reading the ExternalIpAllocator and PlanningInput concepts described in the issue, then trace how IP Pool Ranges are collected and consumed by the blueprint builder. Compare the current fungible-range behavior with the IPv4 and IPv6 service requirement. Done means the planning input and allocation behavior express operator intent about which pools each service uses.