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.
