add mechanism for configuring system image builds

[JeffBezanson]

This adds the option to pass a filename of configuration settings when building the Core/compiler system image (from base/compiler/compiler.jl). This makes it easier to build different flavors of images, for example it can replace the hack that PackageCompiler uses to edit the list of included stdlibs, and makes it easy to change knobs you might want like max_methods.

~~Will need corresponding changes to PackageCompiler.~~

[Seelengrab]

Kind of tangential, but having full-on Julia source code as the configuration file format seems VERY dangerous, especially if people start sharing these. Would using a TOML be an option instead? That would also have the advantage of making the configuration file easier to document in terms of what the compiler actually looks for in the configuration options.

[KristofferC]

It would at least be good to have support for setting these from e.g. Make.user (similar to how one sets JULIA_PRECOMPILE, JULIA_CPU_TARGET etc).

[JeffBezanson]

TOML would be good, we just don't yet have a parser available at this stage. It will be awkward, since we don't even have arrays or dicts at this stage.

The target user for this is code like PackageCompiler that is building custom system images. I don't expect anyone to change these settings just when building julia with Make.user. For comparison, currently PackageCompiler literally rewrites the file sysimg.jl to make changes like this. So the threat model is like somebody sending you a file and telling you to replace sysimg.jl with it --- obviously that is dangerous and we can't prevent it.

[Seelengrab]

TOML would be good, we just don't yet have a parser available at this stage. It will be awkward, since we don't even have arrays or dicts at this stage.

Yeah, I figured.. It's a bootstrapping thing all over again!

[JeffBezanson]

OK I have a better implementation:

• Core.Compiler and Base each have their own settings, since they are separate libraries. You can pass --settings to either.
• In the process, DRY the buildroot argument to the Base image build
• No more unreadable intrinsics code
• Backwards compatible with existing PackageCompiler

[JeffBezanson]

Decided to call this "buildsettings" to clarify they are build-time.