Add an initial plausible bounds_checked_int.

It only works on 64-bit processors,
and arithmetic mixing bounds_checked_int sizes doesn't compile
in this version, and it requires a bit much explicit casting
(for paranoia's sake to make sure the user doesn't miss somewhere
that could overflow).
Improve/fix bounds_checked_int significantly.
Finish fixing bounds_checked_int, and actually test all its operations.

This is the first version of bounds_checked_int I got to work
(compile and run correctly) with the rest of the Lasercake code
(commits for that are coming later).
fix the concurrency_utils test
make a way to compile all the sources at once (so you can see if it works)
Add typedefs that will make using bounds_checked_int practical.

polygon_collision_detection.cpp gets some explicit casts from
0 or 1 to rational (non_normalized_rational<polygon_int_type>) [1]


[1] because it wasn't working for me with bounds_checked_int...
maybe it was the fact that it would require *two* user-defined
implicit conversions
(int -> bounds_checked_int -> non_normalized_rational)
which C++ won't do (but it will do a builtin implicit conversion
and a user-defined one).
Make Lasercake math variables almost all signed.

This is because:

C promotes signed to unsigned when you mix their arithmetic,
which can be annoying.  Signed is mildly more useful than unsigned in
most cases (whenever you don't want a modulo type or don't need *all*
those bits for numeric magnitude), and a bit less likely to
accidentally underflow.

Also, if you don't want modulo behavior, signed permits the compiler
to optimize assuming overflow/underflow won't happen (this lets it
believe useful things like (for all int i, i+1 > i) which affect loop
optimization and others).  Normally I would also be nervous about
the undefined behaviour when it *does* overflow.  However,
* we're going to get that anyway, because lots of our numbers do need
to be signed.
* wrapping would probably lead to other bugs in our code even if it
was compiled as fully modulo (-fwrapv -- which [note to self] I might
try adding sometime and see how it affects performance).
* having bounds_checked_int helps convince me that we are not
overflowing in the typical case, even if it's too slow to run in
production.


The tile_physics change was trivial.

The tile change required changing world_center_tile_coord to still
have vast swaths of numeric space on either side of it.  That's all.
Make the rest of the code compatible with bounds_checked_int

This requires including its headers in order to be compatible
with it, but still compiles fine without actually using
bounds_checked_int (as intended, for runtime speed [and compile
speed?] purposes).
Fix a minor int-size limit/bug found in the process of debugging

(It might be better to also check if more is being subtracted from
the velocity than its magnitude, or similar, and do something
sensible in those high-velocity cases.  Such cases probably can't
occur presently for other reasons, but.)
Add the (off by default) way to enable bounds checked ints.

(With optimization in each case,
on 64-bit Linux, GCC 4.7.0, Sandy Bridge i7 CPU
)
runs around 30 times slower than non-bounds-checked.