Change way types are stored and represented + allow for more than u16::MAX types

[kaleidawave]

Currently all types are currently held under a single Vec<Type>, and TypeId is pointer into this vector. TypeId is a wrapped for a u16. To support larger files/codebases this needs to increase

• Currently the sequential ids require the whole program to be checked (from a starting point). Adding more incremental parts will create problems if an intermediate file is changed. TypeId has to be split between libraries/files somehow.

• Also from Add binary type caching back and think about TypeId #103: Adding versioning or something to the binary format that can be checked on deserialization. This is because new versions of the compiler might have a different representation in byte form (new fields, removed enum members, etc) that isn't compatible to be parsed with binary files generated by older compilers

[kaleidawave]

Quick thoughts:

Considering struct TypeId { block: u16, offset: u16 }. Where BlockId points to a collection of Vec<Type> that can span multiple files / packages. But each block only contains types per module so that invalidations have a limited effect or something.

[kaleidawave]

I think the first thing is to split types apart.

TypeId should be InterfaceTypeId | ConstantId | FunctionId | ... with each of them having their own Vec

Could try splitting types that an expression can represent from conventional types again at some point. Although makes subtyping less simple

[kaleidawave]

Worth considering whether Type::And and Type::Or should be Vec rather than binary tree

[kaleidawave]

Additionally for Type::Object(AnonomousObjectLiteral) it would be great if the properties could be inline rather than on through environment (they are fixed for this type, can't be modified or merged)