Make Availability Zones a real data model

In Nova, the concept of the availability zone is one of the least well-defined in the system. Problems around availability zones are numerous:

 * There is no data table in the Nova database for availability zones

 * There is no nova.objects.AvailabilityZone or nova.objects.AvailabilityZoneList

 * A compute host can belong to multiple host aggregates, each having a separate availability zone -- which makes no logical sense

 * The nova availability-zone-list CLI command and its associated os-availability-zones API extension is an abomination that loops through **every single compute host in the entire Nova database** via the nova.objects.ServiceList.get_all() command in order to produce what is typically a list of *one* availability zone.

The root cause of this problem is really that there was an early assumption that a single Nova database would only ever serve a single availability zone, therefore there would only ever be a need to store AZ information as configuration options.

Therefore, there are a number of seemingly random CONF options that have to do with availability zones:

 * `default_availability_zone` -- This option is ONLY ever used in the GET /os-availability-zones API command, as a string substitute for any compute host that does not belong to a host aggregate that doesn't have an availability zone tagged to it's extra specs. Otherwise, this option is entirely useless, and frankly, confusing due to the actual use of the other related CONF options

 * `default_schedule_zone` -- This option is used by the scheduler to determine which availability zone to place a new VM instance into if the user did not specify one. Only thing is... since the scheduler is only able to communicate with a single availability zone (the one it is in), this option is next to pointless and actually results in misunderstanding due to its default value being None, which has caused bugs (https://bugs.launchpad.net/nova/+bug/1451921) due to misunderstanding.

 * `internal_service_availability_zone` -- Nobody seems to understand at all what this option does or was ever used for.

A fix for this mess is really an overhaul of the availability zone concept and implementation inside of Nova, including:

 * Determining how and where to store this higher-level information like regions and availability zones, if not in the Nova database itself

 * Creating a real data object representing an availability zone

 * Actually have the Nova database (or some data store) keep records for known availability zones

 * Having the Compute API return these AZ records instead of the bastardized weirdness that is currently in nova/availability_zone.py

 * Entirely detaching the concept of the Service (and ServiceGroup API) from the concept of availability zones. This means internal_service_availability_zone CONF option should die in a fire.