avr32 screen render could use some work

[catfact]

each refresh, bees checks the dirty flags on each of its regions (the scrolling region, which covers the whole screen, the 1-line header region at the top, and the 4 footer regions along the bottom.)

in the screen driver, we have "regions" (aka rects.) each region is a byte array and a dirty flag.

if any region is dirty, it gets blasted to the OLED, using one of the functions in here:
https://github.com/tehn/aleph/blob/dev/avr32_lib/src/screen.c#L157

the OLED controller is capable of changing the scanning boundaries on the fly, so each redraw just has to send bytes for that rect.

nevertheless, there is room for optimization. for one thing, there is a copy-and-pack step (on the line linked above, and duplicated elsewhere.) i think some kind of pack is necessary because the controller represents each pixel as 4b, but in the drawing routines we use 8b per pixel. the thinking around that was that it would be more efficient to have the drawing routines not have to deal with pixel-packing, because they get called more often. (e.g. we don't want to put extra shifts/masks/or's in each column of each glyph in a string-rendering routine.)

but there is also the fact that the screen is mounted "upside down" according to the controller (see comment on the linked line.) we deal with this by inverting the data in the copy-pack step. but i think there is probably a way of setting up the controller so it scans backwards. i think if we didn't have to invert we could get a bit more clever with the pointer manipulation in the copy-pack.

there's also way too much copy-paste in screen.c , could stand some refactoring...