Flawed conflicts( ) produces current overflow

Of course, if I had shown myself the grid earlier rather than relying on
Eclipse's debugging facilities I'd have seen that nothing changed from
earlier except that the recursion is now unlimited. By earlier I mean when
print worked, it showed me that conflicts was satisfied with almost all 1s
in the guess cells. More mysterious is that occasionally it pushes it up
to 2. Conflicts( ) bears more scrutiny.

I vetted upperLeftCorner( ) and corrected extraneous copying from nX/nY.
I realized that they could be the multiple return values I sought and were
safe since I change them (via next/previousCell & upperLeft) before immed-
iate use.
Still overflowing, on 4x4 even

Something deep is wrong in the flow. This generates hundreds of calls
when 64 should be the upper limit. I've corrected some bugs but this
still eludes me. (The conflicts seem to check out now.) Frankly, I'm
pretty close to really studying someone else's code to compare mine
against. (Also inclined to not make these hard line breaks in the commit.)
Solved some overflow, eerie terminations

It turns out that when I backtracked from an untenable guess onto a clue,
the clue always pushed the focus forward in an infinite loop. If I had
considered the calls more carefully, I would have been in a better
position to realize that. So, for the moment, there's a backtracking flag
until I think of something nicer.

Unfortunately, it seems I may have fouled up that implementation anyway.
The 4x4 puzzle reported failure when it had half the puzzle solved.
Further, the 9x9 overflowed trying to backtrack past 0,0. I
need to vet thisFirstCell(), in case it isn't preventing the backtrack.
Overflow solved, subtle termination beneath

It turns out that I hadn't been terminating when 0,0 was a clue cell and
previousCell() didn't push it back further (which it shouldn't).

Unfortunately, the algorithm terminates too soon. I know that both have
solutions, but this quits after trying insufficiently. 4x4, it solves half
and then chokes when it can put down a 4. However, it can do so since it
has already guessed a 4 earlier. I guess I'll scrutinize the conflict
checks further. 9x9, it tested a few guesses and then quit. I guess I'll
also scrutinize the similarity between both. To be honest, I'm reaching a
saturation such that I may look at them but am just as likely looking at
my internal representation while my eyes are in the direction of those
symbols.
Solver works

I am so pleased. Decided to knuckle down on the conflicts which pointed to
squareConflict which finally revealed that upperLeft() was giving garbage
values. I'd have noticed sooner, but hadn't been testing effectively for
an irrational fear of printing too many values to see the proper pattern.

I had broken through my earlier resistance to looking at other's
techniques and had a proper upperLeft to hand. It seems most github
sudokus don't advertise backtracking, and most I checked don't use it.
They seem to prune their search space. (Although hohenzollern has a scala
version that tests various AI/constraint algorithms.)

I left this with solverIteratively() for the moment. The recursive version
hasn't been updated since I branched and may have a hidden danger. (I'll
merge back to origin next.) Now that I can have a solution, this will
print that to a file and another array. I'll wrap it in an interactive
terminal and then move to swing. Quite exciting.
Prep for merge

Validated recursive algorithm. Didn't matter though, because - although 6x6
succeeds - 9x9 overflows. I can specify a larger stack through eclipse,
but I can't control client JVMs. So, iterative is the default until I move
to a language with more sensible tail recursion.

I also changed the clue designation from an offset to negative values. As
I plan to have arbitrary possibilities, any offset would conflict. Much
better to march in the opposite direction.