add FFI linux framebuffer interface
Merge remote-tracking branch 'upstream/master' into ffi-framebuffer-native
remove RGB16

we won't likely use it, it is full of bitops, thus pretty slow
fix accidentally deleted types
one type deleted that really is gone now
bugfix for value setting
factor out POSIX API
blitbuffer with much more optimized blitting

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.
use blitbuffer API for conversion

now that blitbuffer API for A8 format exists, we can use the output
of mupdf directly.
adapt blitbuffer API test to deletion of RGB16 format

RGB16 was dropped since it won't likely be used. Reflect this by
removing the according test routine.
Merge branch 'blitbuffer-optimization' into ffi-framebuffer-native
fix for rotation modes

4bpp handling was a bit adapted so rotated 4bpp can now be handled easier
remove test function from blitbuffer.lua

tests are now in our test suite
Add FFI implementation of drawcontext

Drawcontext was a bunch of accessor methods to a C struct.
We can do this easily with FFI.
Switch method to get drawcontext struct pointers from Lua

This change is backwards compatible - it will still work for the old
way of passing Lua userdata objects.
remove Lua header inclusion from drawcontext.h

drawcontext.h now only serves to provide the declaration
of the drawcontext struct.
Major rework of blitbuffer.lua (again...)

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).
Adaptions and bugfixes for SDL framebuffer emulation

Now properly does rotation.
proper refresh handling, adaptions to new Blitbuffer initialization
Adaptions to new blitbuffer initialization