Provide an API extension that exposes the internal image UUID -> S3 image ID mapping

The glance UUID to S3 image ID mapping is not exposed directly by nova, which creates difficulties for EC2 API proxies and image replication tools.

In the former case (e.g. AWSOME or a future deltacloud EC2 frontend), the proxy has no way of mapping from the given ami-* ID passed via the RunInstances call onto the glance UUID required in the ImageRef on the onward native API 'POST /v2/{tenant_id}/servers' invocation used to spin up the instance.

In the latter case, even if the replicated image has the same glance UUID in the destination region, the S3 image ID is very likely to differ from that used in the source region due to the auto-increment style of ID creation which completely depends on insertion order.

Different approaches that would address this include:

 1. Expose the glance UUID via the EC2 API, e.g. by shoe-horning the UUID alongside the glance name property into the DescribeImagesResponse name field.

 2. Conversely, expose the S3 image ID via the native openstack API, e.g. by adding it to the image metadata.

 3. Provide a new S3ImageIdMapping API extension that explicitly exposes a bidirectional mapping between the two ID forms.

Option #1 runs the risk of breaking established clients, option #2 pollutes the native API & glance with EC2-specific data, whereas S3 provides a clean new mechanism to expose this to clients who may need it.