Small refactoring of CodeGen classes to fix naming of CodeGen, make LLVM logic common.

This PR makes the naming of our CodeGen classes a bit more logical and eliminates duplicated code in compiling for LLVM. I originally started on this while tracking down the optimize_module crash, which turned out to be something else, but I feel this is an improvement to the code and sets up some other changes as follows:

1) Adding a top-level CodeGen class which is independent of LLVM. This should make some parts of StmtCompiler cleaner and can make it clear that functionality such as function_takes_user_context is not connected to LLVM.

2) CodeGen_Posix should go away. It has nothing to do with Posix and can either be folded in to CodeGen_LLVM, or made into a helper class. (CodeGen_Allocation or some such.)

3) All LLVM specific codegen for GPU backends should be built on Halide IR so that we can do things like call GPU code from the C backend. (There is not much of a use case for doing this from C, but it makes a lot of sense for a JavaScript backend, which I hope we will have.) Hopefully this will allow getting rid of the templated CodeGen_GPU_Host classes.
Right, I'm basically just looking at the logic used in get_initial_module_for_target, and that used to set up the triple in CodeGen_X86 (the most involved target triple logic), and it is mostly the same. It might make sense to do all of that in one place, and it would be nice to have get_initial_module_for_target set up the triple/data layout. It has all the information it needs to do so.