Menu work

[mid-kid]

This PR will contain multiple commits that properly document and abstract menu data and functions.
Putting this here so people can look at it and provide feedback for the time being.

[roukaour]

Can this be split into wMenuData2Flags, wMenuData2_2DMenuFlags, and wMenuData2_ScrollingMenuFlags in those unions? Then the comments about different bit meanings would also go in their respective sections, engine/scrolling_menu.asm can use wMenuData2_ScrollingMenuFlags, etc.

[mid-kid]

No, because some flags and code checking those flags are used for several different menus. See, for example, GetMenuTextStartCoord, which checks bit 6 and 7 of the flags, and is used by both PlaceVerticalMenuItems and Place2DMenuItemStrings.

[roukaour]

Regarding macros for menu data, I think dealing with (x, y, width, height) would be easier than (y1, x1, y2, x2), particularly in map scripts.

A sample menu from CeladonDeptStore6F.asm:

.MenuData:
	db $40 ; flags
	db 02, 00 ; start coords
	db 11, 19 ; end coords
	dw .MenuData2
	db 1 ; default option

.MenuData2:
	db $80 ; flags
	db 4 ; items
	db "FRESH WATER  ¥200@"
	db "SODA POP     ¥300@"
	db "LEMONADE     ¥350@"
	db "CANCEL@"

And with a menu_dims macro:

.MenuData:
	db VERTICALMENU_BIT_6 ; flags
	menu_dims 0, 2, 20, 10 ; x, y, width, height
	dw .MenuData2
	db 1 ; default option

.MenuData2:
	db MENUDATA2_BIT_7 ; flags
	db 4 ; items
	db "FRESH WATER  ¥200@"
	db "SODA POP     ¥300@"
	db "LEMONADE     ¥350@"
	db "CANCEL@"

Theoretically a single menudata macro could pack in all the parameters:

.MenuData:
	menudata VERTICALMENU_BIT_6, 0, 2, 20, 10, .MenuData2, 1

But that could get long when combining multiple flags, and there's less room to add side comments for each bit of data. It also doesn't match the .MenuData2, which can't really accomodate a macro. (At most there could be menudata2 MENUDATA2_BIT_7, 4, but that goes against all the other db N item counts in map script files.)

Anyway, if menu_dims is acceptable, it can be added to map scripts without waiting for full menu flag documentation. Thoughts? (Edit: menu_size may be a better name.)

[aaaaaa123456789]

On everything listed:

1. As long as we don't have newline escapes, menudata is unreadable.
2. VERTICALMENU_BIT_6 isn't more informative than $40. Only use constants if they are meaningful.
3. menu_dims seems a lot more practical than the current method.
4. No macro for the second menu structure is needed (and MenuData2 is a horrible name anyway).

[roukaour]

1. I agree menudata is unreadable.
2. Right, that was just to illustrate "we'll have real constants here eventually".
3. I'm glad menu_dims is looking good.
4. Agreed.

[xCrystal]

Could be wrong, but I think the end coords gives more useful information at first glance than the size, because it lets you picture the four corners of the box right away. That said, a menu_coords macro is definitely more telling than one or two random db.

Anyway, I guess it's up to preference so I don't really mind how it turns out.

[mid-kid]

Ready for merging.