Change typeid definition to be based around the canonical type hash

[gingerBill]

typeid used to be a fancy index with extra metadata stored on it. Now it is direct hash of the type. This means that typeid is now fully deterministic.

n.b. This does not mean you should pass typeid across DLL boundaries still, as this is most likely not work.

The new definition of a typeid is now always 8 bytes on all platforms (rather than the previous definition of being pointer sized), and thus the size of any is 16 bytes with an 8 byte alignment. This does mean there is an extra 4 bytes of padding on 32-bit systems, but this is an okay cost in general for deterministic typeids.

This is safe to do in practice since any possible collisions are checked at compile time AND the chances of having a 1% collision requires ~609K types (see the Birthday Paradox).

Therefore accessing a ^Type_Info is now a hash table lookup with linear probing. The table is twice the size than necessary so prevent too much probing due to an overly dense hash table.

__type_info_of :: proc "contextless" (id: typeid) -> ^Type_Info #no_bounds_check {
	n := u64(len(type_table))
	i := transmute(u64)id % n 
	for _ in 0..<n {
		ptr := type_table[i]
		if ptr != nil && ptr.id == id {
			return ptr
		}
		i = i+1 if i+1 < n else 0
	}
	return type_table[0]
}

As this requires a % operation, it might be a bit costly to gather the type info data. This could be optimized in the future by allowing that operation to be baked at compile time if possible.

[graphitemaster]

LETS FUCKIN GOOOOOOOOO