C compiler used as linker gets hardcoded

[SeanTAllen]

When we switched from gcc to clang as our default compiler, I noticed that the path to the compiler ends up as an absolute one for the linker.

So for example if clang was located at /usr/bin/clang on the build machine, when you install the resulting ponyc on another machine, it will require /usr/bin/clang to exist. rather than just clang.

I don't know if it was like this prior to our switch to cmake as our build system. Either way, we should probably switch so that "clang" is used.

I can see how as an end-user I would want to build so that the linker is hard coded to a location on my machine (if I have say more than clang installed), but that seems more like an edge-case to me that once we make this change, we could look into supporting the "no really, i want to hard code the linker c compiler location".

[jemc]

Some notes from a quick discussion at the end of today's sync call:

There are a few places where the version of clang and the version of LLVM that clang was compiled with come into play.

• We have an LLVM IR snippet that we use for exception handling, and we need to use a clang version compatible with that LLVM IR.

• Users who want to use the runtime bitcode for whole program optimization would only be able to do so if they have a clang version that matches, which implies we'd want to keep that as a somewhat stable contract if any performance-heavy folks are using that feature.