Improve type system and type inference rules

[k-sareen]

As discussed here: #120 (comment), the type system and inference rules should be updated to allow less verbose pattern matching for developer UX.

[titzer]

Can you write a seman testcase that should pass and add to test/fail?

[k-sareen]

I've been reading the type checking code in vst/Verifier.v3 and I don't understand why the ve.expr has to be null, i.e. why the match case has to be the unqualified type (see these lines).

[k-sareen]

For the error generated by test/fail/adt_type_infer03.v3 (in PR), I think the TypeSystem.isPromotable() should return true because, well A<u4>.C and A<u8>.C are the exact same type. Unless is there some internal representation issue? Even then it should just be equal, no?

EDIT: Or well, more precisely the TypeSystem.isSubtype() for variants needs updating.

[titzer]

This is a subtle thing that needs to be explained better. Integer types like u4 and u8 are not related by subtyping but by promotion. That is because they could be represented differently. E.g. on a 32-bit machine a u32 will be represented by one word and u64 two words. Subtyping is only for values whose representation doesn't change when assigning a value from a subtype to a supertype location (i.e. the assignment is always pass-through, nop).