Actually use layouts

[N1ark]

Encoder.rust_to_cvals / Encoder.rust_of_cvals where both poorly named functions and badly implemented; in particular they relied very extensively on the type of the values, and handling layouts manually, rather than trusting the layout of the type.

This PR fixes it! I renamed these functions to encode and decode respectively, and factored out a lot of code and simplified it. The core idea is:

• a value with a Primitive layout is written as-is; we don't even check the type
• a value with a Array or Arbitrary layout has an iterable set fields; iter_fields returns an iterator over these fields and their offset
• a value with an Enum layout needs special treatment to figure out what variant we're reading/writing; however once we know the variant it's straightforward, as above.

There is relatively little additional effort needed! I also separated the validity checks done for references into its own function, check_valid (this comes with the advantage that we can more easily disable validity checks, if we want to one day).

This is the second part of #127

Additional minor changes:

• added some utilities to Iter
• remove the implementation of Binop.Cmp for pointers, as it's never used
• properly remove metadata from pointers when needed

[giltho]

Some nitpicks but overall looks good!

(Reviewing in the Paris metro is not the easiest lmao)

[giltho]

Btw iirc there's an explicit comment in the core lib saying that external users should never rely on the layout of fat pointers. So maybe one day we should make access raw or opaque depending on access within core or outside.

[N1ark]

hmm this could be interesting yes ! i remember @Nadrieril mentioning that slice layouts or their ABI might eventually become guaranteed, so it would be nice to figure out progress on that (pinging because I cannot find a source anywhere:P )

[Nadrieril]

The RFC is here: rust-lang/rfcs#3775. Looks stalled for now

[N1ark]

ahhh nice thank you !

[giltho]

(You need to promote files)