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.
This is part of the "theory of operation" of this change that needs to be explained. Who is responsible for calling the serializer, and how do they do it? I don't really understand yet.