Proposal: Add identity information to container environment

Add a set of standard environment variables to docker containers to provide identity information.

# What?
As far as I can tell, the only way a container can (easily) get its own identity at present is to look at the HOSTNAME environment variable or /etc/hostname.  This will provide the short ID of the container.  Furthermore, this the short ID, which is not guaranteed to be unique, and says nothing about the running image.

The attached implementation, by default, adds a few environment variables to the default container environment.  These variables provide the full container ID, the full ID of the image the container was created from, and the hostname of the docker host on which the container is running DOCKER_CONTAINER, DOCKER_IMAGE, and DOCKER_HOST respectively).

This behavior can be disabled by adding `--stdenv=false` to the run or create commands.

# Use Cases
## Debug Isolation 
In large environments, you might (for example) have a few dozen docker hosts running the same web application behind a single load balancer.  If a single container instance is failing in some subtle way, it can be difficult to isolate.  To combat this, the container ID and hostname can be stored in a log somewhere with the associated request identifier, or even passed through as a comment in a web page, allowing admins to easily determine exactly which container generated that page.

This is, perhaps, more important in compute-centric applications where there are hundreds of nodes with logs aggregated centrally.  By logging this information at the application level, the location of a failure can again be isolated.

## Automatic Cache Busting (or, why I actually did this!)
Anyone who works with web apps (especially with CDNs involved) knows that browser-level and other content caches can be a pain to deal with.  If you deploy a new version of an application, you have to make sure that you don't request and/or use a previous version of your javascript and other assets.  This is a common problem.

A typical solution is to add a query argument to the end of a request specifying the desired version of the asset.  The problem is that maintaining this is often error-prone; developers with insufficiently-automated workflows occasionally forget to update values.

With the addition of this patch, this version information can now be automatically generated based on the ID of the particular image the container is running.  This ensures that all assets are correctly versioned -- and tied not to the application, but to a particular build, represented by a docker image.

For Example:
```php
<?php
function js_version() {
  // Tie the version to the image ID, but keep the actual value private.
  return md5("salt" . $_ENV["DOCKER_IMAGE"]);
}
// ...
?>
<script src="/some/js/file.js?v=<?= js_version() ?>"></script>
```

# Notes
- I have a running argument in my head as to whether or not a "NOSTDENV" type command should exist so this can be disabled in a Dockerfile.  My guess is that nobody would use it, but who knows?
- I did consider adding the short ID's as additional variables, but ultimately decided against it.  They can easily be derived from the full ID's, so it's mostly pointless IMO.
- There may be other information that could be presented this way, but I couldn't think of any offhand.
- This is my first exposure to Go.  The feature itself is simple and straightforward, so I don't expect trouble.  Someone should probably review the unit test code, though!  It struck me as way too complex for such a simple test.