split some graph.c related headers

[mzxrules]

No description provided.

[AngheloAlf]

In MM we put all those macros in a different header, one that has the z_rcp.c function declarations because the files tend to use those macros and the rcp functions together.

I guess an argument can be made for the Open/CloseDisps and Alloc functions which are not present on MM.

[mzxrules]

idk it feels a little more sensible for these macros to exist in graph.h since gfxCtx is a graph.c stack variable.

I also did a once over and realized that most functions don't even need to be exposed outside of graph; the only oddball is ThreadEntry.

[mzxrules]

Contributions made in this pr are licensed under CC0

[mzxrules]

sorry for the rebase, but there were extra files being shown as being modified that I didn't touch.

I'd like to recap where this PR is currently, explaining some of my decisions for what goes where and pointing out some new changes.

It was suggested that what is graph.h, gfxbuffers.h, gfx.h as defined in c1e57dc should be one header, but I think it's reasonable to keep them separate.

graph.h is meant to be specific to the graph thread and related tasks. The GraphicsContext is located here because it represents state important to the graph thread. WORK_DISP, POLY_OPA_DISP, POLY_XLU_DISP, OVERLAY_DISP and OPEN/CLOSE_DISP are here because they ultimately provide access to Graph_ThreadEntry's gfxCtx instance on stack.

gfx.h has had a lot of things split out of it, but I decided to keep it around to store the z_rcp.c types/function declarations because I feel it's just a little cleaner to do so. For one, main.h only needs the graph thread entrypoint not the drawing stuff, and two the z_rcp.c functions/dlists are not strictly necessary to do drawing. Currently, gfx.h includes graph.h just because I didn't feel like forward declaring GraphicsContext at the time. Not sure if I should keep it as is or not.

gfxbuffers.h is separate from graph.h because generally most things aren't allowed to access these buffers because the memory is being shared between the graph thread and the RCP. That said, I'm feeling less confident about this split.

As for other new changes.

I did a documentation pass on gfxalloc.c and standardized all uses of Gfx_Open/Gfx_Close. I'm not entirely sure where this belongs. While Gfx_Open/Gfx_Close are generic, all instances follow the same pattern of "opening" and "closing" POLY_OPA_DISP for writing to the point where there should be a macro that simplifies this in graph.h Perhaps this should be split off to a different PR altogether.

Introduced ucode_disasm.h, pretty self explanatory.

[Dragorn421]

graph.h and gfx.h are the same thing (both are "graphics") and shouldn't be split