[WIP] Added three example project templates

@smarterclayton @bparees @danmcp I moved the gists to a PR so people can comment and send PR's with changes (and comment on those changes ;-). 

Previous Clayton's questions (copied):

>  Define image repositories as well here

You mean PEP [Image Repository](https://github.com/openshift/openshift-pep/blob/master/openshift-pep-013-openshift-3.md#image-repository) ? Will that repository be defined in JSON by the `imageRegistryURL`? Do we need to have the set of metadata (`metadata: [ {...} ]`) and if so, do you have any examples of the metadata in your mind? (i can think of a 'tag' (?))

> Need to have a discussion about whether build configs and image repositories should be uniquely identified, or a getOrCreate call.

The work flow in my mind is:  The `service` references `image` which is coupled with the `buildConfig/image`. If the Docker image does not exists on minion, then Docker will pull it ('get') from the image repository. If the image is not available in the image repository, it will be built and then pushed into image repository specified in the `buildConfig`.

> Speak with Cesar and Abhisheck but a podTemplate is probably a child of a deployment which is a child of a deployment config, which is a child of a service. We might be able to collapse a deployment config and a service, but not sure

@abhgupta ^^

>  Can we track what env is exported via the links instead?

We can and actually I like it as it is more descriptive (what is exported to where). However, exporting between projects might be tricky, because perhaps you want to restrict what vars will be exported from one project to another.

> Is "from" an id or name? Is there a use case where you need to link across projects? Or not?

The "from" is service id. In new schema I call it "service": "ID". The use-case is right there, you have redis-cluster project, with several services you want to handle independently from your application project. Then you want to link these two together. Alternatively you can have N other projects, you wanna sync via Redis cluster. @bparees ?

@smarterclayton @mfojtik per the discussion this afternoon, it sounds like links are being dropped entirely.

@mfojtik I still think you should merge what you've got and we can evolve, but the new idea as I understand it is to simply define all env variables at the project level, and then reference them from anywhere you want them to be available (ie both a ruby container and a postgres container would have a reference to $DB_PASSWORD, and the project itself would define DB_PASSWORD=generate()  (syntax for example purposes only))

network linking between containers (and injecting endpoint information for remote containers would be handled by defining what k8s calls a service (what i'd rather call an endpoint or endpointcluster) and anything that wants to use it (eg a ruby deployment wanting to use postgres) would include a reference to the service/endpoint/endpointcluster definition.

@smarterclayton that about right?