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`
Okay, I'll keep that in mind.  I originally had link.exe as something that
find_system_linker looked for, but it wasn't usable at the time.
-E

On Sun, Nov 30, 2014 at 12:05 PM, Jameson Nash <notifications@github.com>
wrote:

> In contrib/build_sysimg.jl:
>
> > +    println("System image built; run julia -J $sysimg_path.ji")
> > +end
> > +
> > +# Search for a linker to link sys.o into sys.dl_ext.  Honor LD environment variable.
> > +function find_system_linker()
> > +    if haskey( ENV, "LD" )
> > +        if !success(`$(ENV["LD"]) -v`)
> > +            warn("Using linker override $(ENV["LD"]), but unable to run `$(ENV["LD"]) -v`")
> > +        end
> > +        return ENV["LD"]
> > +    end
> > +
> > +    # On Windows, check to see if WinRPM is installed, and if so, see if binutils is installed
> > +    @windows_only try
> > +        # Silently fail on windows if LLVM < 3.5
> > +        if convert(VersionNumber, Base.libllvm_version) < v"3.5.0"
>
> 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
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/JuliaLang/julia/pull/8074/files#r21062944>.
>