fix display wibble (move code before a short-circuit return)
Add a column-based worldgen-function-writing mechanism.

With more implementation work it can be used for a lot more
than it already is, but in the meantime, e.g. spiky2 generates
three times faster than spiky does. (column- vs tile-based
versions of the same thing.)
Merge branch 'master' of https://github.com/elidupree/Lasercake
Add omitted boostbcp headers.
Add a way to make more-deterministic pseudo-random scenarios.

And add a version of spiky that uses it.  I'm getting
spiky2 250ms init
spiky3 270ms init
which is not a bad price to pay, although if we can eliminate
some of the other costs of worldblock initing then the RNG
initialization will be a higher cost to pay.

The taus88 generator was plenty fast but generated
obviously-not-random-enough worlds.  The Mersenne twister variations
were somewhat slower to init.  ranlux seems to be a fine
in-between point.  Boost docs say its speed per random number
is quite low, but for these memo purposes each instance of the RNG
is not making that many numbers, so that faster init time than
mersenne-twister beats mersenne-twister in speed here.

There are other ways to do it that I haven't tried
(e.g. if you need very few random bits, you could MD4 hash the
arguments to get those pseudorandom bits; I didn't have a MD4
implementation on hand to test that's speed quickly).
This is fine for now.
rearrange specific_worlds code order

put the various world-impl structs next to each other
Make simple_hills use newer infrastructure.

This only decreases its worldgen runtime by about 10%.
Halving max_simple_hill_width makes the runtime about 1/4,
which means that the cost is linear in that:
i.e., the cost to look up all those memos in a hashtable for
every x and y, since the memo shares most of the actual computations
of get_hill.  It's interesting that there wasn't a significant
improvement from changing from tile-spec to column-spec;
maybe the optimizer was good enough to share some of the lookup work
in the previous version (worldgen_from_tilespec_t makes it plausible
the optimizer might do something like that).
Make 'spiky' default to best impl so far
add accidentally uncommitted note
make specific_worlds make_rng dubiously more reliable
Use all of the hash in the RNG seed.
Fixed last remaining known assertion failure with objects motion code
Fixed some rounding issues.
Merge branch 'master' of https://github.com/elidupree/Lasercake
de-hack bbox_collision_detector_tests include
Loads of experimental versions of object motion code...

Making this commit was the first thing I did after recovering from my
   carpal tunnel, in order to make sure I didn't lose anything when I
   started modifying code I hadn't looked at for months. It leaves the
   code in a broken state with lots of abandoned junk lying around.
refactor globallocal_view_dist -> global_view_dist

(It didn't have any effect for the local view.
The multiplication by it was only there to prevent rounding error,
so I used a constant instead.)
rename view_direction -> local_view_direction

It's more accurate.
Make view able to focus on any (ish) specific object.

The view defaults to ROBOT view, which starts out pointing
at the 'robot' currently.  The selected object is stored
in LasercakeSimulator::currently_focused_object_.  It can
be any object_with_eye_direction.  Pressing tab changes
the currently focused object, in an order based on object
creation (object_identifier numeric order).  Keypresses
that an object reacts to (currently only 'robot' reacts to any)
are only delivered to the* object that is selected (currently,
an object is selected even when in GLOBAL or LOCAL views,
which I left unchanged in this commit other than changing the
default view from GLOBAL to ROBOT).

Next: have objects say things about how they are controllable
(print a string as heads-up display info).

* or sometime in the future when we let multiple people play,
multiple objects that are selected at once, each controlled by
their own screen+keyboard.
fix commit & add optional instruction strings for player