Improve Pal cache spatiality; fix install mode

The struct pal lost its r, g and b members in favour of a more
cache-friendly rgb uint32_t member.

Instead of 07455, which I suspect to be a typo, the correct mode is, of
course, 0755.
Correct README

I'm not done with the accompanying changes but this is urgent because the
text is embarrassing.
Use local libraries

We don't have to install the libraries anymore which speeds up development
by the nanosecond it takes to do that...

Ignore vim's swap files for commits.
Make inherent library fb support optional

This is accomplished by two measures:
a) Build time: inherent framebuffer support can be disabled by setting
   CONFIG_FB=n to the make process. This _can_ be omitted. It is just there
   to prevent it from even being compiled to reduce size;
b) Run time: tgfb_init() now takes a pointer to a struct tgfb_output wherein
   function pointers are stored to be called at occasion. Note that each of
   these functions must be implemented.

The tgfb_set_output() function was added to provide the above functionaliy
in a dynamic fashion.

Note that since the library is now fb-agnostic, some function names changed.

The worst thing, however, is it's ridiculously inappropriate name. Let's
keep the acronym, because I have *absolutely no* wish to rename the project,
but call it 'Tile Graphics For the Bold' :-)

The sources will not compile at this point because I'm now rewriting the git
history. Yes, I'm the man from the future here! :-) These big changes here
are heavily related to the optimisation structures added in the next commit.
However, both changesets are really too big for a single commit as you'll
see.
Introduce optimisation API

A struct opt carries a bit vector which represents 'items' in another
structure. These items can be clean or dirty. These states are used to
cache data and/or (re)compile portable data into non-portable data which can
be acted upon more quickly at runtime.

The concept of 'items' is a versatile design. The application code shall
make use of items the way they want to, i.e. they can translate the linear
items to a n*m matrix - but they must do it themselves.

Palette and tile understand optimisation 'items' as lines in their data, so
they always recompile entire lines if at least one element in the line is
dirty.

The ->opt->uptr inside library structures is used by the library internally,
so hands off!

There are _lots_ of implicits in the way optimisation is done and interacted
with the output devices (some space is assumed to be malloc'd by the output
device, etc.). This should experience a clean-up later.

Recompilation takes place transparently. I'll keep an OPTIMISATION section
in the documentation of each relevant function.

However, the user must mark the changes they make to library structures by
setting the optimisation data appropriately.

Note carefully that if objects depend on each other, this does _not_ hold
for their optimisation data, e.g. a tile will depend on its palette to
regenerate itself but if the palette is dirty, the tile will not
automatically be recompiled according to the new palette. This must be done
explicitly by the user by marking the tile entirely dirty when they change
the palette. Keeping a tileset around (which lists all tiles that belong to
a particular palette) may be handy in this case. This is not a very pretty
solution but changing palettes is something you shouldn't do anyway ;-)

This is a real problem, though, when a 'global' palette changes, i.e. a kind
of colour theme of a map changes. But normally, as I said, this is bound to
a map structure which _has_ a tileset where all affected tiles could simply
be found and marked dirty.
Implement a backbuffer

We have a private backbuffer which can be used by first calling
tgfb_fb_begin(), then drawing whatever is to be drawn and then tgfb_fb_end()
which awaits the fb's vsync and then puts all changed pixels onto screen.

Note that this does not currently make use of the optimisation structure.

The changes from this and the two previous commits would satisfy tagging for
v1.99 as I did early when the commits were unsorted but I can't for my life
get a compiling commit done so the v1.99 is left out. 2.00 will be with full
optimisation support.
Optimise palettes

The output device must convert the palettes' RGB colours to whatever it
natively handles - in the compile_palette() callback. This saves a lot of
palette lookups which is a quite critical path.
Optimise tiles; fix tile drawing bug

Tiles get (re)compiled into fb colour blobs within ->opt->uptr to save the
palette lookups.

It is now very difficult to maintain statically allocated tiles and stuff.
The tetris example migrated to using a file, too, for its 'black' tile.

Fix bug in tile drawing routine which would have led to wrongly rendered
pictures when only part of the tile would fit on screen.
Handle errors when loading tileset

Correctly handle errors in tgfb_tileset_load().
Implement tgfb_out_fill()

This function takes a portable RGB colour definition and a struct map_region
to fill that rectangle with the given colour.

This addresses a quirk in the tetris example where a file for an entirely
black tile was created just to properly load it and its optimisation data
to erase other tiles.

Alas, it was necessary to define a new callback in the output device
structure for that because I don't want to provide low-level callbacks like
set_pixel() or convert_color(), etc. which could be used to implement that.
These would not be very tile-ish, so...