Design change to the Move class:
	Two things that felt wrong:
		1) Some Move objects will be half-constructed temporarily (move history) or permanently (enumeration of legal moves)
		2) A Move object can't determine by itself which piece moved, whether it was a capture, check, checkmate, or stalemate.
	What if we recompute the notation whenever needed, on the fly?
		* Depending on the GUI implementation, making n moves may result in O(n^2) notation calculations
	Observations:
		* Whoever determines move notation needs to know the relevant board states and the move itself (the Chess class).
		* Move notation can be stored as such; it isn't necessary to have 3 or 4 boolean variables for check, capture, etc.
		* Move notation should be cached to avoid recalculations and potential O(n^2)-time behavior
	Conclusion:
		Put it in the Chess class, because we have access to the relevant board states and the move itself.
		[Maybe the parallel arrays in the Chess class can be made into a single array of Turn objects...]
