[Ohrrpgce] Choice Boxes overhaul

[Ralph Versteegen]

So (on a whim) I was about to start on a HeartBug request to add more
textbox choices and allow longer choice text. For years, I've held off
doing any such thing, thinking it would be better to just convert
choices to menus, or at least, to convert SAY to RELOAD. But that
still seems a long way off, due to the weird ways textboxes and menus
interact, which I don't look forward to trying to solve. Plus I didn't
totally like the idea, because the menu editor is scary and not  so
convenient, while the choicebox editor is wonderfully simple.

Now, extending the length of the two existing choice text will be
messy, but doable. SAY is already the messiest of all lumps, anyway.

But if there are more than 2 choices (I was thinking, say, 5), then
setting a tag to determine the next textbox/script isn't going to work
well for more than two choices. Better to just directly set the next
textbox/script on a choice. Not having to name a tag, set it, and test
it in the conditionals menu will be huge improvement too!

...Would be nice if you could set choice colors too.

Putting all this in the choice menu (and in SAY) would be really
messy, it would be better to have... the menu item detail editor.

We already have support for multiple files containing MenuDefs and
MenuDefItems (the MenuSet UDT), though I don't know why that was
implemented.
So I'm proposing converting the choice box in-game to a MenuDef,
adding a new menuitem lump for choicebox items, but not a new lump for
the choicebox menu itself. Many of the settings in MenuDef don't make
sense (eg on-close script, most bits) or are determined by the
textbox.  Omitting the top-level menu editor will make the choicebox
editor simpler. Plus we can very easily add it and a dedicated lump
later, with no backcompat headache.

Maybe I will hide a couple of the things in the menu item detail menu
- the extra data and the "Close when selected bitset. Maybe I should
disallow the Special menu item type too? But I don't really see a
reason to.

For now, the choicebox menu could just be unable to scripts until the
textbox-menu mess is cleaned up. Or maybe handles for menu items in
the choice menu could be obtained with a special script command.

The only problem I see is that the choicebox currently has some
slices, and if they are replaced with a draw_menu call (which can be
done from a SpecialSlice to ensure correct layering/position), they
could break scripts. Actually, I doubt anyone uses them anyway.
But actually, I could easily enough create a new function to set up a
rect slice, scroll slice and text slices to draw a MenuDef.