Add circle CI setup

This pull requests adds a first version of a circle CI setup. Its currently limited to run postgresql builds in parallel per subproject. This PR originates from a discussion [here](https://github.com/spree/spree/commit/42933ff22bf143e5b83abaf3fc56b4df676e2abc#commitcomment-8231199),

It currently only builds spree on postgresql. To my experience this build setup results in very deterministic builds with around 5min round trip time. ( A bit longer on recent master, it slowed down due DB heavy tests).

Future improvements could involve also building against mysql in separate parallel containers to not increase the build time. CircleCI [free for OSS plan](http://blog.circleci.com/a-step-into-open-source/) currently offers 3 containers. This will result in building 2 subprojects in one container (the build scripts scales down automatically). You'll not reach the 5min round trip time we got in our spree fork this way. I suggest the company behind spree simply buys an extra container or pings the company behind circleci for free containers - Especially when you also want to build on mysql in parallel.

It should still be faster than the current teamcity setup as the gem installation is cached through builds. The cache invalidation / update works fine through `bundle check or bundle install` logic. This also happens what downstream users will have as their `bundle install` runs depend on the locally installed gems. It turned out the root cause in the related discussion was exactly the use of more recent gem API without bumping the dep.

Sprees spec suites still suffers from random failures. Even after the [SKU fix](https://github.com/spree/spree/pull/5452) we PRed in the past you'll see some DOM races in the feature specs. These are not the fault of this setup and might require to restart a build once in a while. (Ideally fix them, but this is out of the scope of this PR).

You should be able to see example builds here: https://circleci.com/gh/MountainRoseHerbs/spree

Even with this build setup I see lots of possible improvements. Its just a start and I suggest working in small iterations.
It seems like the suffix for both log calls is the same. Maybe you could create a local variable for the log suffix rather than using `human_node_index.