Remove thresholded image generator code.

Given that this is an optimisation branch, this debug feature isn't
needed. It's also never triggered, as thresh_img is always null.
Reduce reliance on the 'labelled' image.

Currently, the marker detection code produces an image that has a record
for each pixel, labelling what block of dark pixels it belongs to. This
is nice and simple, but for a 1280x720 pixel image that's 1.8Mb of data,
more than the greyscale image (labels are uint16_t's).

This data is read into memory, written out, re-read during 'clip'
creation, and then randomly accessed during contour following. Which is
a large amount of bandwidth, on an ARM core that doesn't have a lot.

So reduce the labelled images uses. First, we compute the clips
on-the-fly during pixel labelling, and perform some later juggling when
label aliases are merged. One line of old labels are stored in a
ringbuffer to detect adjacent labelled pixels; this means we don't have
to depend on the labelled image.

The topmost dark pixels in a clip are also calculated on the fly -- this
reduces the logic in first_labeled_on_top_row, and means it doesn't have
to interpret the labelled image. The aim is to reduce the labeled image
to a one-bit-per-pixel image, dramatically reducing the amount of memory
thrashing required.
Make the labelled image just a large bitfield.

That is: we label pixels as either being light or dark, indicated by a
single bit, stored in a huge bitfield. It'll probably turn out that
there's a much more optimal way of writting the access expressions, but
this should reduce the amount of memory bandwidth required.
Reduce addressing overhead writting labelled img

That is, quit spending a huge amount of time calculating the label
address.