Asserted the (unimplemented) line-to-line intersection case doesn't happen.

Even if it was implemented, it would have weird behavior;
   if someone creates a situation where it would happen, they are making a
   mistake, as this assertion will inform them.
Lots of coding towards the line-of-sight algorithm.

(This is still quite incomplete, volatile, and not compileable.)
Mostly generalized horizontal and vertical lines to axis-aligned lines
Continuing line-of-sight algorithm work:

templatized stuff between aalines and plines, implemented things
Continuing line-of-sight algorithm work:

finished (short of bug-fixing and mistakenly omitting things)
   the logical_node_lines_collection type.
Continuing line-of-sight algorithm work:

Holy shit, did I finish it?
Well, I've finished the implementation, anyway, but not the
   "making it actually work" part.
And I've only done this part of the code - not the part that will
   actually decide what hlines/vlines/plines to input based on the
   actual physics.
And I haven't implemented allowing it to handle non-axis-aligned,
   non-pointing-through-the-origin lines, which will require me to figure
   out the imprecise-rationals thing so that it doesn't cause overflow
   problems, which I also haven't done.
And I haven't documented what this cool gadget does.
   Including here in this commit message.
Added (and didn't test!) arithmetic operators for non_normalized_rational

This is in pursuit of completing the line-of-sight algorithm
Continued line-of-sight algorithm work: It compiles!
Implemented visualizer for line-of-sight stuff. It runs, but fails.
Continued line-of-sight algorithm work: Lots of bugfixes
Continued work towards line-of-sight-algorithm: Fixed innumerable bugs
Fixed... can it be..? ALL the remaining obvious bugs in the LOS algorithm!
Line-of-sight algorithm: Fixed more bugs; it is in some sense "finished"

as in, it seems to work accurately when input distances are up to 2^16
(a bit short of the 2^(64/3) I was shooting for; I see how to get there,
   but it would be slightly less than trivial.)
The main things to do next are
  1) further *conceptual* development
       (how will we handle arbitrary lines? It currently relies on being
             exactly right, which would make approximation awkward?)
       (how will we optimize isometric perspectives?)
  2) cleanup
       (we need to document this stuff)
       (and it needs a non-hacky interface to the outside)
Line-of-sight algorithm: Added a way to check visibility without inserting
Line-of-sight algorithm: Added GPL notice
Line-of-sight algorithm: Properly split into .cpp and .h
A band-aid solution to some water physics issues.

Water "explosions" will be less likely now.
The "aggregate changes and make them at once" is not used because it
   caused a segfault; I suspect that it simply uncovered a bug in some
   other code, but anyway, let's not break everything.
Changed autorobots into tunnel digging bots.

They go in the closest horizontal cardinal direction to the one you're
   facing as you tap 'm', and either are "horizontal tunneler",
   "upwards tunneler" or "downwards tunneler" depending whether you're
   facing up-ish, down-ish, or pretty-straight.
The downwards tunnellers don't dig for 10 tiles so that they won't dump
   right on top of their own tunnels.
Oops! ACTUALLY added collection_of_obscured_area_boundaries.cpp

I seem to have forgotten to commit this when I first created it.
Merge branch 'master' of https://github.com/elidupree/Lasercake