support upgrading LM engine

[pmrowla]

In theory, we should be able to upgrade older LM games to the final LM3 engine version. This will require:

1. Replace the original interpreter exe with latest interpreter version
   • should also copy some things like .ico icon bitmap from original exe into the upgraded version
2. Replace LM system LSB scripts

Since the LM interpreter is backwards compatible, and LSBs all contain version information used at runtime, as long as the interpreter is the latest version, it will still work with old LSBs, so the actual user-generated LSBs (i.e. game script) don't need to be modified at all.

This will make certain things easier in the future:

• Old games will have access to system params from newer LM versions (PR_FONTCHANGEABLED support for old games)
• Only need to support PNG->GAL/X conversion (#36), since we can just require LM version that supports GAL/X
• Distributing a modified version of the LM interpreter itself if/when we ever have a hooked and patched version that supports utf-8 (#14)

[pmrowla]

things that will need to be done for this:

• [ ] make lmpatch always replace LM system (novelsystem) scripts with most recent version
• [ ] make lmpatch always replace LM interpreter exe with our custom exe
  • (minor) should also copy misc things like icon bitmap from the old exe into the new one
• [ ] support hexedited encoding field in most recent interpreter exe
• [ ] define our own LSB version (latest ver + 1) to mark files as pylm-only LSBs
  • this will prevent old (unpatched) engine versions from trying to run pylm-only LSBs
  • this is safe since LM is no longer developed and there will never be another LM LSB version
• [ ] replace (hexedit) interpreter exe "max supported LSB version" field to the pylm version
• [ ] add custom pylm-only TpWord version that we can use to specify encoding
  • safe for the same reasons that defining our own LSB version is safe
  • version field is a 32-bit uint (but LM only ever uses up to 100-something)
  • we can define our version to be:
  • (codepage & 0xffff << 16) | (version & 0xffff) so the upper 16-bits are codepage for this text block, and then the normal version int (zero codepage will be default cp932)
• [ ] replace interpreter exe "max supported TpWord version" field to 0xffffffff

for extracting/inserting/patching we will need:

• [ ] extracting - no real changes (since encoding will be defined through the lsb version fields, extraction scripts dont need an --lsb-encoding option)
• [ ] inserting - will need --lsb-encoding option (default to cp932)
• [ ] patching - lmpatch will need encoding option (to hexedit the codepage global constant for the LM interpreter)

things to research:

• do we need to replace all the strings in an lsb or just the ones we care about translating
  • i.e. will having a mix of cp932 and strings in things like untranslated string literals/pathnames/etc potentially break the engine (since we are hardcoding the engine codepage to not-cp932)
• what to use for "sane" engine defaults
  • default messagebox properties (PR_FONTCHANGEABLED)
  • default messagebox font (probably will depend on codepage)
  • etc

[pmrowla]

we probably also need to include codepage in the upper 16-bits of LSB version, since we should also support custom codepages for non-tpword strings (i.e. menus, string literals in calc, etc)

edit: most of the version constants we care about in should be labeled already in ghidra, for future reference we probably need to look at

gvar_defaultLsbPageVer
gvar_lsbParserVersion

it looks like I forgot to label the TpWord one, but whoever implements this should be able to find it again by looking at the TpWord.parseBlock function in ghidra