scrollable framebuffer logs

[hawkw]

now that we can handle keyboard input (see #358 and #363), it would be cool to make the text that mycelium logs to the framebuffer be scrollable with the up and down arrow keys (and Page Up / Page Down as well).

this would actually be a kind of big and annoying change, since we currently log by writing pixels directly to the framebuffer, and once we've written them, we throw away the text that we formatted the log line to. this is good, since it means logging is very lightweight and we can start logging stuff really early in the boot process, and inside the allocator...but it's also bad, because once text has scrolled off the top of the framebuffer, it's Gone Forever.

we probably want to change this so that we can log stuff to a text buffer, and print that to the framebuffer.

as i see it, we have two options here:

• a dynamically allocated text buffer.
  • this means that we can't log to the buffer until we have the allocator set up
  • we also couldn't log to this buffer from inside the allocator, or from ISRs (probably). so, we would need to either never log in those cases, or switch between logging to the text buffer and logging directly to the framebuffer (annoying!)
• a fixed-size ring buffer
  • this is almost certainly the better option because it can be written to from anywhere, and it also means we can't oom the kernel by buffering too many logs (we would probably want to implement some kind of max capacity if we used a dynamically allocated buffer anyway)
  • this could be either statically allocated or dynamically allocated
  • if it's dynamically allocated, we would still need to wait until the heap exists to set it up, but once it's set up, we can write to it from anywhere without having to allocate
  • if it's statically allocated, we can just create a big static array and not have to worry about alloc at all, which is nice, but there isn't really a great way to allow the user to configure how much of a scrollback buffer they want...

[hawkw]

we probably need to dynamically allocate the text ring buffer because we don't know how many characters long the frame buffer will be at compile-time, unless we want to figure out line wrapping when drawing the text instead of when generating it.

the other option is to just have a ring buffer of characters, rather than of lines, but since the goal is to scroll the logs, a ring buffer of lines seems nicer...