scanSub() rewrite

[dgets]

With all of the different issues that are going on with scanSub(), it might be a good idea to just rewrite the whole thing. Some of it is implemented pretty gross at this point, anyway. This is related to issues like #213, #209, #198, #180, and probably even #129.

[dgets]

FWIW: It doesn't matter if one is going backwards or forwards, instead of displaying a message, the entire scanning routine is stopped.

An example of what's going on with a forward scan (and an alleged new message in Babble>):

And afterwards it concludes with showing the debugging output from when (already at Babble>), a reverse scan is initiated:

[dgets]

With commit: c3af3d9, this is now starting to include modifications to the encompassing control structure in readNew().

[dgets]

During testing of the previous commit I realized that a useful pattern to whether or not a new message scan is being triggered hasn't been documented yet. Upon embarking a new scan, the first anomaly is that in the first room, the last message is always displayed. This maybe isn't such a bad bug, but it is still undesirable behavior indicative of scanning pointers being dealt with incorrectly.

With each of the other rooms, it appears that one new message is not enough to trigger a new message scan, but two or more do. This appears to be some sort of a messed up pointer mathematic and/or comparison issue. Comparisons are made primarily in findNew().

[dgets]

Closing this as I'm in the process of starting a completely new rewrite of both scanSub() and readNew() that should combine them and fix the whole shebang. scanSub()'s behavior when specified as forward being true should suffice for what readNew() was doing, anyway.