…ative

we won't likely use it, it is full of bitops, thus pretty slow

this introduces the ability to implement n:m bpp optimized blitting.
This allows for a major speedup. Comes with implementation especially
for from/to 4bpp blitbuffer blitting.

now that blitbuffer API for A8 format exists, we can use the output
of mupdf directly.

RGB16 was dropped since it won't likely be used. Reflect this by
removing the according test routine.

4bpp handling was a bit adapted so rotated 4bpp can now be handled easier

tests are now in our test suite

Drawcontext was a bunch of accessor methods to a C struct.
We can do this easily with FFI.

This change is backwards compatible - it will still work for the old
way of passing Lua userdata objects.

drawcontext.h now only serves to provide the declaration
of the drawcontext struct.

Optimized blitting is removed for now. 4bpp buffer handling is greatly
simplified by using Color4{L,U}:set(...) methods.

Inversion and rotation are now done by setting according flags for blitbuffers.
Flag storage is done in the "allocated" uint8_t struct variable of the classic
blitbuffer struct which is still unchanged (and thus compatible to "classic"
C blitbuffers as they were before going to FFI).

It is quite fast even without optimized blitting routines. Nevertheless, the
method to implement optimized routines is still present, so optimized routines
could be created later on. It is probably not wise, though, to focus on 4bpp to
much now that we can work with other formats, too.

For a lot of rendering, we still do 24bpp or 8bpp to 4bpp conversion in C land,
then another 4bpp to 8bpp or 16bpp conversion in Lua/FFI when blitting to the
framebuffer. This could further be reduced to one conversion (if at all).

Now properly does rotation.

both methods didn't take inversion into account. Now their implementation
respects inversion.

do not build old einkfb, blitbuffer and drawcontext modules
use the FFI implementations in koreader-base wrapper