static compile part 3 (modules)

This prepares the serializer to be able to handle incremental loading (aka module caching). Currently there is no interface to it exposed to the user (other than the raw interface I demonstrate below for testing). Static compile part 4 to add the user-friendly interface will be developed shortly, but I wanted to go ahead and get this merged first since that is a separate task. Part 4 is expected to be easy technically but has more UI questions to answer.

```julia
julia> @time begin
           FP = ccall(:jl_restore_new_module, Any, (Ptr{Uint8},), "FixedPointNumbers_cache.jlc")
           C = ccall(:jl_restore_new_module, Any, (Ptr{Uint8},), "Color_cache.jlc")
           C2 = ccall(:jl_restore_new_module, Any, (Ptr{Uint8},), "Cairo_cache.jlc")
           G = ccall(:jl_restore_new_module, Any, (Ptr{Uint8},), "Gtk_cache.jlc")
           Gtk.GLib.__init__()
           Gtk.__init__()
       end
elapsed time: 0.691674234 seconds (14420556 bytes allocated)

julia> evalfile(Pkg.dir("FixedPointNumbers/test/runtests.jl"))

julia> evalfile(Pkg.dir("Color/test/runtests.jl"))

julia> evalfile(Pkg.dir("Cairo/test/test_speed.jl"))
<output clipped>

julia> evalfile(Pkg.dir("Gtk/test/tests.jl"))

julia> # All tests passed :)
```

note: this would have been fully compatible with the current serializer, except that I changed the deser_tag hash-table (with indexes from 0 to 255) into an array.
the serializer will be invoked in a sandbox, just like it is now, perhaps even continuing to use `--build` as the argument. that allows julia to have complete control over the module's / serializer's environment (similar to how `Pkg.test` works also). Some of the finer points of how the user will enable or disable this are being left for future pull requests (such as #8745, but see also various comments in this PR for other options)

as for when would this be called, for serialization it would go just before the `JL_GC_POP`
https://github.com/JuliaLang/julia/blob/e3a74ee93309576f8a8dfc9812e0922a1ea88dfe/src/toplevel.c#L153
if in `build_mode`, and `last_module == jl_main_module`

for deserialization, that is less clear, perhaps jl_restore_new_module will be more-or-less directly exported for the user with an interface roughly equivalent to the existing require/include (perhaps there should be magic bytes at the start of the file indicating that it is a cache file, and dispatching accordingly in `jl_load`?)