GdbServer: Support 32-bit context definitions

[Sonicadvance1]

Requires restructuring a couple of things, but nothing too crazy here.

First commit is from #4203

[neobrain]

Making all this compile-time-based increases the code complexity here a lot. Have you considered using a runtime-based approach via std::span instead?

bool is_64_bit;
GPRType gregs_storage[NUM_GPRS];
std::span gregs(gregs_storage, is_64_bit ? NUM_GPRS : NUM_GPRS / 2);

AFAICS we only need binary serialization in one place. We can do a little more work manually there, at the benefit of saving all the template ugliness this change currently adds (most notably GenerateAndFetchContextDefinition.template operator()<GDBContextDefinition>...).

[Sonicadvance1]

I don't see what you are intending here? We give the connected gdb instance a layout that is defined via BuildTargetXML and we need to ensure that the resulting binary that we encode and send over the pipe matches that exact struct layout, which differs between x86-64 and i386.

This is probably just me being daft since I don't quite understand what the intended change does.

[neobrain]

we need to ensure that the resulting binary that we encode and send over the pipe matches that exact struct layout, which differs between x86-64 and i386.

Yes, but we aren't required to use the exact same binary structure internally. IIUC the binary layout of GDBContextDefinition(_32) only matters in CommandReadRegisters, where we serialize using encodeHex. If we do this serialization manually instead, we can merge GDBContextDefinition and GDBContextDefinition_32 into a single, non-template struct.

This would require boilerplate similar to what's in CommandReadReg now, so it could even make sense to go one step further and drop the use of structs altogether and describe the GDBContextDefinition data as a raw memory block with a fextl::vector-based array that dynamically describes each member.

I'm not strongly attached to any particular way of going about this, but the template approach seems overly clever when runtime-based approaches would produce code that's simpler to reason about.

[Sonicadvance1]

The struct definition is technically used in both CommandReadRegisters and CommandReadReg in different ways.
But I've removed any amount of being "clever".