Fix update_symbol_addrs.py compatibility

[scarletcafe]

The old version of the script does a lot of manual parsing with hardcoded offsets into lines and so on, which no longer works due to both modifications made to the relevant files since the script's creation, and the fact these offsets can vary between versions.

This PR changes a few things:

• Allows you to specify an argument e.g. python tools/update_symbol_addrs.py jp to specify a version to work with instead of current.
• Reworks most of the manual parsing to be regex-based, so it is a bit more robust
• Uses dataclasses with named fields instead of various tuple and list based anonymous types (making it easier to read the code that uses them).
• Adds type hints to make the script pass with pyright in strict mode (makes it easier to examine the script in IDEs)

I have not committed the actual update symbol_addrs.txt files because the script, being automatic, removes all of the manually authored comments, but the updated script runs for all supported versions and I can add them in if desired.

[ethteck]

Thanks for working on this. my preference would be that we use mapfile_parser instead, as it has pretty much already solved the problem being attempted in this script. I was meaning to update it at some point, but I never got around to it..would you be willing to modify the script to use it instead?

[scarletcafe]

Sure thing. I'll take a look through it and see how I can rework the script.

[scarletcafe]

I've changed the mapfile parsing to use mapfile_parser. From what I can see, its calculations for ROM and RAM addresses match the existing script, although mapfile_parser is much better at figuring out the file and section related to a symbol.

We don't output any of the additional info mapfile_parser gets us within symbol_addrs.txt itself, so I've put in an --output-json and --output-csv flag in as a bonus, and also added a -v/--verbose flag to enable the existing verbose logging without needing to modify the script itself.