Rib Robustness: Make sure the type building using AllOf and OneOf isn't giving memory pressure.

[afsalthaj]

After multiple scanning for type inference going on, we keep building the types using AllOf/OneOf. For example: it looks AllOf(all_possibilities_of_record) is looking pretty huge!

Recently (first week of Sept), we made sure we are not storing duplicate types, and there are no logical errors in this side.
Yet I believe we still have a considerable memory footprint that we need to be cautious about. I will be doing a benchmark before we plan the solution for this ticket.
May be this is not an immediate issue, yet placing a ticket to track it down later.

There are various ways to handle this building of large data structures representing types.

1. Maintaining a table instead of attaching the inferred type to every identifier as an optimisation. Expressions may not repeat, but identifiers do!
2. Pre-unification strategies instead of accumulating types that could have gone through an obvious unification. Example: No need to keep this towards the end AllOf( Result { ok: Some(U64), error: Some(Unknown) }, Result { ok: Some(U64), error: Some(Str) }). We could come up with a progressive type elimination to keep the memory footprint low
3. And a lot more...

Or may be there is a known theoretical way of doing this, and need discussions with @jdegoes .

[jdegoes]

It's easier in GC world because the values can be shared more easily. I would suggest two obvious things:

1. Use a canonical representation: either "and of ors" or "or of ands".
2. Use a set for the "ands" and a set for the "ords" so you don't store duplicates.

These two changes should have a very good effect.