Needing a cleaner separation of operations in `codegen.cpp`

[DanilaFe]

@riftEmber and I took a look at the codegen pass today to see if it could easily be made to work with the compiler driver to generate multi-architecture GPU executable. In particular, we were hoping that instead of the ad-hoc fork that the GPU backend does, we could simply invoke another version of chpl --driver. However, the main issue that we ran into was the fact that the codegenPartTwo code (which needs to happen post-fork) uses the AST.

At present, we don't preserve the AST between runs of the compiler driver; only the LLVM module / C files survive from phase one into phase two. Thus, to "integrate" the GPU fork with the compiler driver fork, the post-fork generation of GPU objects must be stripped of all uses of the AST.

This raises a few questions:

1. Is this even possible, or is there some GPU-specific during-codegen behavior that requires the ASTs?
2. How can we re-arrange / disentangle the AST-dependent code from the AST-independent code?

These questions would also affect whether or not we can remove the 'special casing' of the GPU compilation in compiler driver mode.

[e-kayrakli]

Maybe naive: can we generate LLVM modules for CPU and GPU pre-fork, and than post-fork have LLVM compile those modules into different target machines?

[DanilaFe]

That would be the hope, but I'm not certain it's possible (I think "what architecture this is for" needs to be set post-fork, but LLVM modules need to know this at configuration time).

[mppf]

Another aspect here is that we currently only work with 1 LLVM Module. There are several scenarios where we might need multiple modules in the longer term, though.