Disabled nightly build by changing an element that would normally schedule a job.

FullBleed complained on Discord about the performance of this MTscript
function.  It turns out that the algorithm is O(n), so putting 3200
entries in a table gets seriously slow.  Fixing this will require the
supporting `LookupTable` class to have its own `setTableEntry` method.
This commit is some simpler formatting and refactoring fixes; the next
commit will be more substantial in regards to the actual fix.

Part 1, laying the groundwork by adding documentation and correcting
warnings in the affected file(s).  WIP.

Finished adding tests of the model.  I'm not thrilled with the
ExpressionParser class being used directly by LookupTable, but changing
it to use DI is beyond the scope of this issue.  When the LookupTable
changes its implementation to a sorted array, the dependency can be
changed (perhaps).

Should the MTscript functions have tests as well?  Or should those be
done via a macro within the tool?  It would certainly be easier to
automate if they were in Java, but putting a bunch of testing macros
into a campaign would (potentially) allow others to build tests as well
and contribute to the project.

(TODO) With the use of `macro.catch`, maybe exceptions thrown within
MTscript can actually be caught and handled in a sufficient way?

….toString()

This reverts commit ee9a535.

This reverts commit e1796d2.