Proposal: Kubernetes Build Plugin

We propose that a build plugin and corresponding framework be added to kubernetes to facilitate: 

1. Leveraging Kubernetes' scheduling, resource allocation, and garbage collection in order to provide docker image build capabilities to users
2. Third party systems wishing to use OTS Kubernetes as a build-farm
3. Organizations using a third-party CI server to orchestrate docker image builds as part of their devops SOPs
It's also possible that there should be two dimensions to "declarative resources" - the "current/now" (what the REST API returns) and then the audit / historical record that is managed out of band, and accessed via different APIs.  Here they're both modeled together because a build is a kind of "single use controller".  It would be possible to move the historical aspects to a different model / resource structure after they are complete.

I think history ties into pods in general - in #1007 Brian mentioned "the api resource shall remain for a certain amount of time before being deleted so clients can reliably create them" might also play into some discussions here.  Should there be a shadow concept of the pods that used to exist?