Add proper microversion support

Discussion on etherpad:

https://etherpad.openstack.org/p/horizon-microversion-support

THE PLAN:

    - Create per-service dict of feature implementations, with a list of explicit versions that are known to work.
    - Service provides a MAX version (called 'latest') and a MIN version (called 'min_version')
    - When deciding whether to show a feature on the dashboard, check the versions for that feature, in decreasing order, against the version range provided by the API.
    - Use the highest acceptable version, based on the premise that newer should be better (faster, more secure, etc)

... in slightly more detail
    1) Feature dict would look something like:

    MICROVERSION_FEATURES = {
        "service_1": {
            "feature_foo": [ 3.11, 3.14 ]
        },
        "service_2": {
            "feature_bar": [ 2.3 ]
         }
    }

    2) Retrieve (and cache) the services MIN and MAX versions as a tuple, for example:

        SERVICE_1_MICROVERSIONS = (2.1, 5.2)
        SERVICE_2_MICROVERSIONS = (1.0, 1.9)

    3) Add some magic to allow an easy check for a given feature. This might look something along the lines of:

        is_microversion_feature_available("service", "foo"):
            <horizon_feature_implementation>

        Behind the scenes, we'll want to find the highest intersection between the list specified by Horizon and the range available in <service>_MICROVERSIONS tuple.

Tricky parts to consider
    - Microversions can break. There are no guarantees that something will be consistently implemented, or implemented at all between API microversions. Because of this, we should be explicit about which microversion to use.
Reference: http://docs.openstack.org/developer/nova/api_microversion_dev.html#removing-an-api-method
- When adding a new microversion feature, we should have at least two versions; the oldest known working version (this should be in the API docs as the version that introduced the feature) and the current version of the API that this works against. This should allow newer Horizon versions to keep compatibility with older deployments, so there is no reason not to upgrade Horizon.
    - We may end up having to main multiple "feature implementations" per feature, if something was heavily rewritten between microversions. These should probably be listed as separate list items, for example:

    {
        "foo": [ 1.0, 1.1 ]
        "foo_1": [ 1.2 ]
    }