When copying a battle script and pasting it elsewhere, if some of the pointers are back into later points in the same script, the new pointers should point into the new script. Do this by checking for relative labels before checking for absolute addresses.
Merging lists takes a long time. Since we want the pointer sources to be sorted at all times, lets expose that detail and take advantage of it to allow us to merge-sort any time we combine tables together. This significantly increases list-merging speeds.
* Allow battle scripts to _not_ add a new code body if the code body contains a subset of already found code.
* Allow battle scripts to include XXXXXX: labels for parts that have things pointing directly to them.
* Improve battle script parameter recognition.
* remove undo within script editor textboxes
* properly clear formats when a script gets shorter
* properly clear formats of where pointers used to be when a script changes
* When checking for a need to repoint, use the proper script type
battle scripts are almost identical to pokescripts in how they work. Each command has a single-byte code, followed by some number of arguments, each of which are 1 to 4 bytes.
Because of these similarities, we can reuse the same engine code and just load the engine from another file. So the code tool can have a 4th mode and basically just work for free. Runs for battle scripts can be as simple as XSE runs: just a single byte, don't bothe decoding, show decoding only in the tool.
Still to add: how to know which battle script commands are ending commands, or which ones point to other battle scripts, or which ones point to strings. How to view battle scripts in the editor? Etc.
* Add XSERun, which right now is just a 1-byte header that marks the start of a script segment.
* Add the ability to cascade down through script segments to find all endpoints, adding XSERuns and pointers as needed.
Previously, the creating a new ViewPort loaded from 2 text files and creating a new HardcodeTablesMoel loaded from 1 text file. This is a lot of parsing!
Refactor to do the parsing once, in the EditorViewModel, using a Singleton class to hold the non-editable loaded data. Inject that data into the appropriate structers later on.
To prevent massive refactoring in the tests, not every ViewPort needs to be given a Singletons instance. Instead, allow a ViewPort to still do its own parsing. However, BaseViewModelTestClass has been updated to make this work for a majority of tests, along with changes to AutoSearchTests's fixture and several of the Setup methods that are used by multiple tests.
Being able to dissassemble ARM code is only half of the code that hackers want to see. They also need to be able to read/write pokescript, often done via tools like XSE. Eventually I can be more intelligent with scripts, but for now a simple decoder is plenty.
