Define a "task status" mechanism

Idea from a discussion with @bcantrill:

So, we can pretty-print basically any Rust type we find in any program (that was compiled with debug symbols) at this point. We also have a few use cases where it would be nice to show the status of a task. One example is showing task disposition settings from jefe.

Rather than building task-specific knowledge into Humility, which I dislike, we could define a debugger interface for status information, e.g.

• Each task can define a single top-level no_mangle symbol called TASK_STATUS (or something)
• Humility is aware of this and, if it's present, can pretty-print its contents.
• humility tasks can show status, either every time or (more likely) on request. This is a semi-verbose mode, less aggressive than showing the full TCB with -v, and more useful to people who aren't kernel developers.

Then, if a humility subcommand has specific knowledge about a task, it can use reflection to load the type out of TASK_STATUS and do whatever with it. Like enabling the jefe command to read out disposition info.

Obvious-to-me uses would include:

• Stuffing an enum into it showing "current status" as a sort of summary of info that might also go into a ringbuf
• Counters for event types in the fields of a struct

The issue does not name files, tests, or an entry point. Start by locating the existing task display and debugger reflection interfaces, then determine how a task-level status symbol could be discovered and rendered. Done means the interface and its use by humility tasks are defined and implemented, with coverage for the proposed status information.