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.
Their validity depends on what method definitions exist in the generic function. If you do a bunch of stuff in your julia session, then call `jl_restore_new_module`, is it possible these cache entries could contradict the state of some of your functions?