The bytecode file format uses 28 bits for the type of a global var. However, 
generally speaking, type ids are encoded as vbr_uint32 making it possible to 
use 32 bits for a type id. It is conceivable in some monstrously typed module 
that this encoding will fail (if the typeid of the global var is in the range 
2^29 to 2^31). While this probably won't ever happen in the near term, its 
conceivable that linking together some huge enterprise application could fail 
in the bytecode reader/writer if more than 2^29-1 types are used.

A potential fix is to limit type ids to 24 bits (using a new read_vbr_uint24 
method in the BytecodeReader class). This would give us four extra flag bits 
on global variables should we need them in the future(e.g. new linkage types, 
or "thread local storage"), ensures large type numbers are encoded in 3-4 
bytes instead of 4-5, and provides a reasonable limit on the number of types 
that can be instantiated (16 million). 

This bug is really low priority and shouldn't be addressed unless we need 
extra global var bits. Its logged here so we don't forget about it because its 
a *potential* problem even though there's a very low probability of it 
occuring in the foreseeable future (who uses more than 256 million types? :)

"256M types should be enough for anyone" , sorry had to say it. :)

Sorry, I goofed. Five bits are used for the global flags which leaves only 27
bits for the type of the global var. So the maximum number of types global vars
can reach is 128M. Wow, that's 1/2 as many! We REALLY need to fix this NOW! :)

Fixed commensurate with bug 402 changes.