Implement lists

[quephird]

The following functionality is introduced in this PR:

• Lists can be created using the standard square bracket syntax, e.g., [1, 2, 3]
• Lists can be accessed and mutated by index, e.g., foo[2] = 42
• Lists have a native count property
• Lists can be appended to and have their elements deleted, e.g., foo.append(42) and foo.deleteAt(1)

In order to achieve this, the following significant changes were made:

• There is a new class LoxList that subclasses from LoxInstance. Unlike other LoxInstances, it disallows setting of any properties, and exposes only a few builtin properties, such as count
• There is now a standard library, with one Lox List class for the time being, that is processed upon instantiating Interpreter. The two functions in the builtin List class, append() and deleteAt(), call two new functions defined in the NativeFunction enum where the work is actually done
• In order for the above to work, the interpreter needed to be able to read in and interpret raw Lox code upon instantiation. That necessitated that the scanner, parser, and resolver now have to be instantiated in Interpreter.prepareCode(), which is called in the initializer, rather than outside of it.
• The main Lox class now calls Interpreter.interpret() or Interpreter.interpretRepl(), passing in the raw source code, rather than instantiating the rest of the pipeline before instantiating Interpreter.
• All of the tests in InterpreterTests have their inputs expressed as raw Lox source code strings instead of ResolvedStatement arrays, making them far easier to read.

My brilliant girlfriend, with some help from myself, came up with the strategy above for appending to and deleting from lists because we needed a way of somehow passing a reference to the LoxList instance from its property handler (namely the get() method) to somewhere in the interpreter so that that could mutate its elements. If we tried doing so in LoxList.get() without any other machinery, we would not have any access to the environment, and thus be able to get a handle to this and then mutate its elements. Likewise, if we tried having Interpreter.handleGetExpression() construct and return a UserDefinedFunction instance, we would not be able to express, in Lox statements, the ability to append to or delete from a list, which is what we're trying to implement in the first place!