Test program for optimisation

test/opt.c is a test program for the usability of the opt branch's
additions.

The rest of this commit message is dedicated to what I thought when writing
that program which was the first to explicitly face the optimisation API:

I thought about the need to recompile a tile when its palette changes: This
is cumbersome. It would be good if we - again - could let the library detect
this dependency automatically (in the tile drawing code) and if the palette
was dirty, just pollute the tile.

The problem there is, however, not the performance but that after the first
tile cleaned its palette, the other ones won't detect that their palette was
dirty. This can be overcome with a ->users member for struct opt which
counts how many users want to see that the palette was dirty...

This requires that the library structures are treated opaquely and I must
write access macros and functions for everything... Sigh.

This would also be extremely difficult to bring to higher dependencies like
tile <-> map because we don't want to have an algorithm to mark all
occurences of a tile on a map as dirty whenever its palette gets dirty and
such rubbish...

Let's face it realistically: palettes and tiles are not meant to be changed
once loaded. If they are, the users must take responsibility and pollute the
affected objects up to the highest layer. Maps are changed by animations and
moving characters which will be taken care of.

Nothing changes and this will the maxim until someone comes and changes my
mind about this.