debugger: more granular naming for symbol table types

[dave-br]

This is to address the naming feedback from b39e684. That commit added an enum to identify the type of each symbol table. This PR adds a few enum values so that symbol tables can be more granularly typed. With the PR, the list is:

        CPU_STATE,         // CPU registers, etc.
        DEBUGGER_GLOBALS,  // Debugger global symbol table (e.g., beamx, beamy, frame, etc.)
        CHEAT_ENTRY,       // symbols used in cheat entry actions (argindex, temp variables)
        CHEAT_MANAGER,     // symbols from the cheat manager (frame value, from/tobcd functions)
        LUA_SCRIPT,        // custom symbols added by a LUA script for use from the LUA script

This reduces the set of symbols confusingly identified as global. But the debugger's global symbol table is still named as such (for now) because that’s how the public symlist docs, preexisting function names, and code comments have been referring to it. If you’d like those changed, that’s totally fine, let me know what you’d like. A few candidates: DEBUGGER_GENERAL, DEBUGGER_COMMON, DEBUGGER_BUILTIN.

[cuavas]

I think this is a really bad idea. Trying to make the symbol table know all the places it’s going to be used is poor design. Where the symbol table is being used is not a characteristic of the symbol table, it’s a characteristic of the thing using it. It’s a hack that puts a piece of information in the wrong place.

[dave-br]

Good point. What I'd like to do is to allow the symlist command to provide helpful category headers in its output as future symbol tables get added (e.g., local and global variables from the source code for source-level debugging). I do want to identify what the symbol table contains, not exactly where it's used. For example, I think it makes sense to identify a symbol table as containing cheat variables, but there's no reason to assume it can't also be used by the debugger someday (and vice-versa).

Certainly the comments went too far, and the enums maybe got too granular. This Is a subtle change, but I think it's a step in the right direction?

        CPU_STATE,         // CPU registers, etc.
        DEBUGGER_GLOBALS,  // Debugger global symbol table (e.g., beamx, beamy, frame, etc.)
        CHEAT_ENGINE,      // symbols related to the cheat engine (argindex, temp variables, frame value, from/tobcd functions)
        LUA_SCRIPT,        // symbols related to LUA scripting

Also, referring to this as a symbol table "type" perhaps is going too far. Maybe "category" or "contents" would be a better field name for this enum value?