Update for Ghidra 11.0.2 and various bug fixes.

[Zinfidel]

Hi Dr. MephistO, I hope life finds you well. I think you've probably moved on from this project, but I figured I would leave this PR here for posterity in case it is useful to someone.

This PR accomplishes:

• Updates the plugin categorization to be inline with recent Ghidra refactors, also described/fixed in Fix according GP-4269 #72
• Remove the custom PcodeEmit.java implementation, as recent updates to Ghidra have fixed the 8-argument limit.
• Fixes Psy-Q version detection issues (see below)
• Fixes compiler segment generation for Final Fantasy Tactics and possibly others (see below)
• Fixes .sdata placement for Brigandine, Soul Reaver, possibly others (see below)

The Psy-Q detections bytes and mask had some errors that prevented them from ever being able to match anything. In particular the third byte and mask (0x07 and 0xE0) were mutually exclusive and can never match. I believe the intent was to ensure only the lower 5-bits could contain values here, so the byte value is changed to 0x0. The 7th byte/mask would only ever match version 4.7, rather than 4.x. I changed the mask here as well in order to account for detection of versions 3.6.x.x -> 3.7. This was necessary to correctly detect Final Fantasy Tactics which uses 3.6.1.0. I tested against Vagrant Story as well since I know that was a problem and it works.

Compiler segment detection for FFT did not work because its start function did not contain the instruction pair for calling InitHeap. This is the only game I've tested that has a start function like this, but it's possible others exist. This caused the detection offsets to miss instructions by 8 bytes. A crude check is at the start of the function to account for this possibility now.

The rest of the changes to the compiler segment generation are more complicated. The basic idea is that the assumption that the .sdata section starts at the gp initial value is true frequently, but not strictly. Segment generation for Brigandine and Soul Reaver runs into problems where the .data block would get an unnamed .data.split section created that very conspicuously started on the border of smaller data. Later, the .sdata section got created at gp in uninitialized data.

I changed the code to instead determine .sdata as simply starting where .data ends, and runs to the end of the length of the text/data section as defined in the section table. This has the effect for both games of producing compiler segments like this:

.sdata
RAM
.sbss

where gp is located somewhere inside of the uninitialized RAM segment, and the length of the three segments is ~32KB. This matches up with how the gp register is supposed to be used w/ respect to the .sdata and .sbss section and what I've been able to figure out is that this segment layout is produced by the linker when the gp optimization flag is turned on, which is rare for PSX games. I tested this change in emulators and when overlays were loaded for either game, they would immediately dump a ton of data into the RAM segment.

I have tested other games where the behavior of .sdata lining up with gp is present and the changes do not harm that.

[lab313ru]

Thanks!) it's awesome!