[Suggestion]: Recursive map file reading for sym_info and first_diff

Explain the feature

I'm (again) experimenting with partial linking in OoT, where each spec segment is partially linked into an intermediate file before final link. For example the code segment would be linked into build/segments/code.plf and ovl_kaleido_scope into build/segments/ovl_kaleido_scope.plf. This however makes sym_info and first_diff less accurate with their file reporting:

$ python3 sym_info.py Matrix_MultVec3f
Symbol 'Matrix_MultVec3f' (VRAM: 0x800D1AF4, VROM: 0xB48C94, SIZE: 0xB4, build/gc-eu-mq-dbg/segments/code.plf)
$ python3 sym_info.py KaleidoScope_DrawDungeonMap
Symbol 'KaleidoScope_DrawDungeonMap' (VRAM: 0x8081BB10, VROM: 0xBEAA20, SIZE: 0x1888, build/gc-eu-mq-dbg/segments/ovl_kaleido_scope.plf)

$ python3 first_diff.py --version gc-eu
First difference at ROM addr 0xBA42E0, 0x8081A0B0 is at 0x30 bytes inside 'KaleidoScope_DrawDungeonMap' (VRAM: 0x8081A080, VROM: 0xBA42B0, SIZE: 0x180C, build/gc-eu/segments/ovl_kaleido_scope.plf)
Bytes: 15E101A5 vs 15E101A6
[...]

Each .plf will have it's own .map file in buid/segments/ as well, so it would be nice if these tools could read those map files to find the specific .o file that a symbol originated in.

Edit: I've pushed a branch where I've been experimenting if you want to check it out in context https://github.com/Thar0/oot/tree/partial-linking

Advantage

It would make the tools more compatible with partial linking.

Disadvantage

Probably nothing, it should be possible to make the default behavior the same as before this feature is added.

Example(s)

I was thinking there could be a dictionary that associates a file suffix with a function resolver(Path) -> Path that maps the input object file path to an output map file path to read:

mapfile_parser.frontends.sym_info.doSymInfo(mapPath, args.symname, plf_file_resolver, map_recurse = {
    ".plf" : (lambda path : path.with_suffix(".map")),
})

Any object file name that matches one of these suffixes in the originally opened map file will have the associated secondary map opened and the filename in that map reported instead.

For example

$ python3 sym_info.py Matrix_MultVec3f
Symbol 'Matrix_MultVec3f' (VRAM: 0x800D1AF4, VROM: 0xB48C94, SIZE: 0xB4, build/gc-eu-mq-dbg/segments/code.plf)

The resolver would transform build/gc-eu-mq-dbg/segments/code.plf -> build/gc-eu-mq-dbg/segments/code.map, read code.map from that path, probably do some sort of vram adjustment since the plf map files start at vram 0, and find .text 0x00000000000b39b0 0x25e0 build/gc-eu-mq-dbg/src/code/sys_matrix.o is the object file that contains Matrix_MultVec3f, and display that instead of code.plf

Decompollaborate / mapfile_parser