[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 ?

@mfojtik the ability to put them in a pod rather than having to put them in each container individually sounds like a convenience but not a requirement for functionality.  You could argue for a similar ability to define the variable at the project level and have them put into all containers of all pods in the project, right?  

I guess I don't have a strong opinion either way, but I have a slight preference for the simplicity of just saying "if you want the variable available to the container, put it in the container definition" for now.