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.
While we are refactoring, should we just move all of the llvm::Triple code to our Target class, and then let get_initial_module_for_target set the triple, data layout, etc.? 

That way, get_initial_module_for_target would produce a module that is completely ready for the target, with the exception of the code itself.

As far as I can tell, none of the CodeGen classes do anything to set the target triple/data layout based on any information other than what is in the Target object. 

This would basically reduce the CodeGen classes to be only responsible for generating platform specific optimizations/lowerings, and move all of the module configuration stuff to Target (as opposed to right now, this responsibility is kind of spread between Target and CodeGen).