Making executable semantics support a prelude

[jonmeow]

From a "bigger picture" perspective, I'm trying to make executable semantics have prelude functionality (#766). To try break down how I'm viewing that path:

• Having a prelude means some cross-file compilation.
  • Implement packages and libraries #742, package and libraries, is key to this.
  • Add string parsing and a print builtin #721 is an example of a change towards this goal, as package/import syntax uses string literals.
  • Making this work may involve cutting down on globals, so that state doesn't accidentally interfere cross-file. (Filed Remove executable semantics globals #769 to track this thought)
• When multiple files are involved, we should really be tracking source locations as a file+line instead of a line only.
  • Remove FunctionDefinition's default constructor #735 is an example of a change towards this goal, as I've been playing with implementing this (and need to get back to it).
  • Part of doing more structure around lines in errors was to make a switch easier.
• We've discussed the prelude as implemented in terms of aliases to things in the common library.
  • That's how Alias syntax #749 arose.
  • I may implement some prototype alias syntax to support this.
• Tests need to start using a prelude; probably a standard input cross-test.
  • Long-term this should become the standard library.
• As a prelude starter, I may try reworking how Print is inserted to instead have it look closer to actual code, an update to Add string parsing and a print builtin #721.
  • The idea would be to have Print be a function in a package that a prelude imports and aliases, and that it should be easy to add more things to the prelude.

Some of the refactoring work spins out of this. For example, when doing #721 I noticed we were accidentally printing pointer addresses instead of values, so I switched a little to cleaning that up.

Going past that, what I really want is for it to be possible to start writing the standard library. Implementing String or i32 (#767) as a class would both have their own set of dependencies to explore. I'll probably think about this more once the prelude work feels closer to done. Right now it still feels like there's a lot of work to get there.

Anyways, I'm hopeful this will help pull together some of my PRs conceptually, if I seem to be hopping around.