Use ByteRange instead of FileRange in surface AST

[Kmeakin]

Replaces FileRange (ByteRange + FileId) with ByteRange in all surface AST types produced by parsing and consumed by elaboration. This shaves 8 bytes off each of surface::Term and surface::Pattern, and only makes elaboration slightly more complicated, so ought to be a good performance win.

Size changes:

• surface::Term<ByteRange>: 56 bytes to 48 bytes
• surface::Pattern<ByteRange>: 16 bytes to 12 bytes

[brendanzab]

Oh yeah, I’ve done something like this in the past (having a file id on the elaboration context). It does get a little strange when thinking about how multi-file elaboration fits in. Not sure the best approach there?

Regarding performance, the bigger wins for the binary interpreter is probably going to be related to figuring out how to avoid including spans in values while still allowing us to have decent error messages when the binary interpreter encounters a parse error.

[Kmeakin]

It does get a little strange when thinking about how multi-file elaboration fits in. Not sure the best approach there?

Multi-file elaboration should be fine: use a separate elab_context for each file/module, and share item_env (and any other global state) between them.