Add formatting hints to numbers

[wezm]

Fixes #328

Opening this PR for feedback, before proceeding further. The PR adds int hints so that number literals and number patterns retain their original format. For example:

$ echo 'let x : U32 = 1234; let _x : U16 = match x { 0x1234 => 1, 0b1111 => 2, "head" => 4,  _ => 3 }; _x' | mold -run cargo r -- elab
let x : U32 = 1234;
let _x : U16 = match x { 0b1111 => 2, 0x1234 => 1, "head" => 4, _ => 3 };
_x : U16

Possible further work

• I think the extra IntStyle field in Const messes up PartialEq. Looks like I'll need to manually implement it and have it ignore that field. — I've now done this
  • Oh you totally covered this in the issue I linked "One thing we'll need to consider is to ignore the style hint when comparing constants for equality. We could do this by a custom overload PartialEq, or, by implementing our own method (eg. Const::logical_eq), which will involve updates to surface::elaboration::unification and core::semantics"
• A way to add hints to binary data that is read, for example indicating that table_id in table_record in opentype.fathom should use the ASCII format.
• Pehaps find a better home for the traits etc. that were added to core.
• Propagate the style from the inputs to ops — I had a go at this
• Add some more tests
• Allow hex/bin signed ints and extend this to them
• The ascii format uses big endian... should that be adjustable some how?

[brendanzab]

Looking good so far! I really like the merging used in the primops - it's nice to try to preserve the styling where possible.

Good point about the endianness of the ASCII literals. I wasn't really sure about them when I first implemented them, but yeah, they might require some more thought. 🤔

[brendanzab]

I wonder if calling this AsciiBe would remind us of the endianness of this? But maybe just making an issue about this would be enough.

[wezm]

A little research suggests that the common case is for these to be big-endian (E.g. OSType, PNG, AIFF, RIFF, AVI, WAV, DirectX, OpenType). Seems reasonable to just call it Ascii for now.

[wezm]

Ok I addressed the comments. I originally opened this PR with some parts remaining but many have been addressed. So it's probably suitable for merging now, if you agree.

[brendanzab]

Looks good!