[C backend] Support CLANG eventually (in addition to ICC)

[Related to #20, which is the same thing for GCC.]

If the compiler backends in this repo become full featured enough to be usable, then it will eventually be important to support open source compilers as well as ICC. (Note that this backend is still far from complete -- currently, as of 5/19/14, there is only one full featured accelerate backend, CUDA, with a bunch of incomplete ones: llvm, opencl, ICC.)

This issue is a place to keep track which language features clang exposes that could be a substitute for the combination of `cilk_for`, [pragma simd](https://www.cilkplus.org/tutorial-pragma-simd), and "elemental functions" that we use in the ICC backend.

Things seem to be coming along nicely for getting pragma simd in clang, [as discussed here](http://clang-developers.42468.n3.nabble.com/Adding-quot-simd-quot-pragma-to-Clang-td4037747.html), with [Intel's code available here](http://clang-omp.github.io/). I haven't followed this closely and I don't know how close they are to merging with the clang trunk, much less getting that into a release.

[The effort to add Cilk Plus to clang](http://cilkplus.github.io/) seems to be separate, but it also talks about pragma simd being supported.

If elemental functions are not supported we will need to change our current way of doing parallel loop codegen, where we store the real body of the loop out-of-line (as an elemental function) and make a call to it. Rather, we will just need to inline those bodies into the loop and do some extra alpha-renaming.

The idea for developing this new backend will probably be to further parameterize the existing `EmitC.hs` to support different variants. Which compiler to use is an implementation detail, so it probably does not deserve any new module namespace, rather, an environment variable or function parameter to control the existing parallel C/Cilk backend.