make perpendicular-location-iteration code a bit nicer
fix compat #define

I misread
https://wiki.apache.org/stdcxx/C++0xCompilerSupport
before; it's only the GCC-compatibles that are starting out
with "__thread" for their semi-compatible-to-standard-thread_local
implementations.
move scalar numeric utils into data_structures/numbers.hpp
Delete unhelpful part of i64sqrt.

I thought about it:
What's the difference between this and going through the loop
one more time?
Either way, there is exactly one multiply, one-half chance of a
branch misprediction (unless either uses a conditional move,
which I don't see gcc -O3 on x86_64 using in either case), and
a bit of trivial stuff.  In exchange, this deleted part has
a one-half chance of reducing the distance between lower_bound
and upper_bound to 0.7 (sqrt(2)/2) of its former distance,
while the loop has a *certain* chance of making the distance
*0.5* of what it was before, which is just better.

(This either made stepped_pools 1% faster or had no effect on
speed.)
delete unreachable code

(it was a caller_error_if already)
debug print ztree objs more often in summary

(on the path to tracing down a non-determinism!)
Abstraction for ::bounding_box and related changes

This brings ::bounding_box's interface more in line with
collision_detector::bounding_box's.
It also caught a bug which I fixed - rendering lasers
doesn't actually use a proper min and max, so I added a
spanning_two_points() bounding-box-creator.

On gcc 4.7 -O3, this seems to cost 5% performance :-(
(pressure_tunnel)
but is probably worth the abstraction, consistency,
bug-catching-ness... On clang 3.1 it doesn't cost
so much performance.

TODO: similar abstraction for tile_bounding_box? Not
as much code uses that, so it's not *as* important
for coding reasons.
refactor / slightly speed rendering code

render_tile doesn't seem to have gotten faster,
but the surrounding code benefited from these changes
and I might have gotten an 8% draw-time improvement
(rendering_the_world code, not GL calls, that is).
Change tile_width and tile_height.

The new values make
a fine_scalar unit = 1 millimetre
a tile_width = 2 metre
a tile_height = 0.4 metre

- usable proportions once we put it in the game interface.

(We already decided/guessed that, for what we're planning to use
tiles for, 2 metres is more practical than 1 metre.  E.g. putting
a railroad track along/within a tile.)

This has a performance cost in the draw code (5-20%),
but it looks like it's all in the bbox_collision_detector iteration,
so this just adds importance to our hopes to take the tiles out of the
fine_scalar ztree (issue:
https://github.com/Lasercake/Lasercake/issues/25
)
abstract rational better

(this was useful for trying boost::rational again more easily
[it still performs terribly for this to no benefit to us -
it was just a thought about user robot numbers].
It's probably better code too.)
style
Make mobile_object's member data have an underscore.

It's a bit iffy because it's public ((!) - maybe it should
just be friend object-motion/update-moving-objects) - it
could be protected - anyway, many references are in subclass
methods where it should be obvious that it's a member variable
reference.
fix bounds-checked-int build

(when bounds checking is off, no performance cost)
Add a general PARANOID cmake option for internal sanity checks

that turns them all on.
It's still only giving me a 25% slowdown in stepped_pools:
not bad!
refactor - specific objs share code
move robot's float_above_ground ability into a function
indent & make world member private & re-comment
Change velocity a bit to easier-to-understand units.

The world seems to behave generally the same,
and speed seems unaffected.
Add an absurd automatic robot

it doesn't do much of interest now -
just playing around
refactor