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.
true, but the serializer should have been called as soon as the module was lexically closed (and before calling `__init__`) such that `module_being_serialized ≡ jl_current_module`. the fact that that isn't enforced currently actually makes this somewhat brittle against any changes the user makes that were unrelated to the actual loading of the module.