Support building of system image in binary builds

This commit adds a few new pieces of functionality:

* The `contrib/build_sysimg.jl` script which builds a new system image.  This method can save the system image wherever the user desires, e.g. it could be stored in `~/.julia`, to allow for per-user system images each customized with packages in their own `userimg.jl`, for instance.  Or on a restricted system, this allows for creation of a system image without root access.

* The removal of compile-time `JULIA_CPU_TARGET`, in favor of runtime `--cpu-target`/`-C` command-line flags which default to `"native"` but can be set to `"native"`, `"i386"` or `"core2"`.  This allows the creation of a system image targeting user-supplied cpu features, e.g. `cd base; ../julia -C i386 --build /tmp/sys_i386 sysimg.jl`.

* I implemented runtime selection of the cpu target by adding a new member to the `jl_compileropts_t` structure called `cpu_target`.

* Because all julia executables are now created equal, (rather than before where a julia executable needed to have the same `JULIA_CPU_TARGET` set internally as the system image had when it was built) we need to know what CPU feature set the system image is targeting before we initialize code generation.  So a new function `jl_get_system_image_cpu_target()` is exported, which does exactly what it sounds like.

* I added newlines to the end of a few error messages.

* I found an old parser option `-T` which hadn't been removed yet, so I took the opportunity to do so.

When testing this change out, I found [this gist](https://gist.github.com/staticfloat/93d7050a08ff7bb52373) helpful to put into my `~/.juliarc.jl`
just as a note: once we switch to llvm3.5, we should prefer to use `link.exe`. the llvm-generated object files at that point should be compatible with it, and will include the necessary information to support generation of debugging information. the debugging format seems to be proprietary/secret, so it is not clear to me whether `ld` will ever be able to provide this.

but I don't think that has any relevance to this PR