Allow loading of Smithbox 2.0.0 Project files

[treacherousfiend]

Smithbox 2.0.0 changed how project settings are formatted, as well as where they are, instead placing them in the user's Local/AppData folder.
This at the very least gets them loading in DarkScript, although I'm not a big fan of how I did it, since it feels very hack-y and weird

Here's a breakdown of the changes:

• The Open Project dialog now has a new "Smithbox Project File" filter. It's functionally identical to "All Files" in terms of loading, but should filter the dialog by .json files, since now Smithbox projects are named with the project's GUID rather than just "project.json". Any json file which isn't named "project.json" will be loaded as a Smithbox Project
• I've added a SmithboxProjectSettings class for use with json deserialization with the new project files, which even has different names for some of the same settings (ex. GameRoot is now DataPath)
• ProjectSettingsFile now has a ProjectDirectory variable, since it seemed like the easiest way to pass along the actual project directory since I split the LoadProject function (see below)
• I've split the LoadProject function in ProjectSettingsFile.cs into 3 functions:
  • LoadProject - Contains common project file loading, returns the final ProjectSettingsFile to be used. If ProjectDirectory is not null, it will combine that with the "event" string to make the ProjectEventDirectory file path rather than the json's filepath.
  • LoadDSMapStudioProject - The DSMS/Smithbox 1.0.0 Project loading code which couldn't be shared.
  • LoadSmithboxProject - Converts the new SmithboxProjectSettings class into a regular ProjectSettings for a relatively easy fix to compat. Also writes to the new ProjectDirectory variable.
• TryGetEmevdFileProject was changed to attempt to find the project file where Smithbox stores them. Since they don't have any helpful names, I unfortunately resorted to reading each one until it finds one with a project directory that matches the EMEVD's directory. If someone has 2 projects in the same directory for some reason, this will break, but I don't think thats much of an issue
  • As a side note, I'm a bit confused as to why this function gets called on saving a script when the project is already loaded. Part of the reason this change was needed is because saving would unload the project file and leave only the EMEVDs that got converted to JS in the file list.

This PR also features one other minor change to get it to build on SoulsFormats commit 1dd7171, which moved the Backup function from SoulsFormats.SFUtil to SoulsFormats.Utilities.PathHelper.
Unfortunately, building on the latest version of SoulsFormats would require rewrites to how DCX Compression data is stored, as commit e816bed replaced most references to the DCX.Type enum with a DCX.CompressionInfo struct. Unfortunately for DarkScript's uses, while the Type enum still exists, one of the changes (and reasons for the change) is removing the different DFLT compression type enums for DS1-3 and BB, replacing them with a single struct that stores the different bytes between them itself.

[treacherousfiend]

After using this for the last week or so, this really isn't a good fix and should only be merged as a temp fix if needed until a better solution is figured out.

Due to the fact that every project file is just named with a GUID now in one singular "projects" folder, keeping track of which is which is nearly impossible.

I think a better solution would be to add a custom UI for project loading that automatically reads the project json files and displays them via their actual project name.
Alternatively, I think a button which simply loads the current open projects from DSMS or Smithbox (or other Soapstone servers? I'm not super familiar with how it works) would also work well.