No subject

for pxecfg without adding extra features that would require some
invention of functionality to prevent introduction of untested and dead
code. It could work equally well for other jobs that just require a
user to make a choice between some options presented on the screen, and
if anything else is needed in the future, it should be extensible to
accommodate. The simplicity makes the code size small - ~1k when built
for my platform, vs ~2.5k for barebox's menu code.

An example complexity from barebox's menu code we don't use here is each
menu entry having its own display, destroy, and "call when selected
action" method. Instead, we implement display the same way for all
menus, destroy the same way for all entries in a menu, and the selected
entry is merely returned to the caller for it to handle.

The implementation also hides the details of the menu's internal
structure from consumers of the interface - the menu and menu_item
struct's are not externally defined, forcing all interaction to go
through the function interfaces. Interface consumers provide a name and
an opaque pointer to a data structure of the user's choice for each
item, and the rest is shielded from the consumer's view. This should
help prevent coding errors and make maintenance of the internals easier
by preventing consumers from relying the implementation rather than the
interface.

Thanks,
Jason