Integrated instance addresses and networks

Moved several items from the instance package
to the environ/network package, renamed some
of them, and propagated the changes across:
 - instance.Address -> network.Address
 - instance.AddressType -> network.AddressType
 - instance.HostName -> network.HostName
 - instance.Ipv4Address -> network.IPv4Address
 - instance.Ipv6Address -> network.IPv6Address
 - instance.NetworkScope -> network.Scope
 - instance.Address.NetworkScope -> n.Address.Scope
 - instance.Network* -> network.Scope*
 - instance.NewAddress(es) -> network.NewAddress(es)
 - instance.HostPort -> network.HostPort
 - instance.Port -> network.Port
 - instance.Select*() -> network.Select*()
 - instance.SortPorts -> network.SortPorts
 - instance.ErrNoDNSName -> network.ErrNoDNSName

(I might have missed some, but you get the idea).

Also, some refactoring was done to split addresses and
ports implementation in separate files and test suites.

No other logic changes introduced - the rest is just
mechanically applying the changes above.
I don't think we have to fix that right now, though filing a tech-debt bug, or maybe Vlad you can just pick up the patch and submit one to add more private addresses. It is still really heuristic for this, so having more is good, but I think we want to get to the point where we can have people configure their own public vs private.

We've also had needs where you're working "privately" but some private networks are more private than others. You might be on an internal LAN and be using a 10.0* sort of address, but then your private cloud is on its own private lan as well, in say a 172.* address (I think the ranges were reversed, but we ran into exactly this problem in the past).
So the real fix is once we have network modeling, we declare "these addresses are the private ones, these are the public ones", rather than just inferring them.
But as long as we are inferring them, we might as well infer more.