Input-Recording: V2 File format

[xTVaser]

Description

My main motivation for breaking the file format for hopefully the final time is because of several reasons:

• The current format was not designed with flexibility/extensibility in mind. It has a lot of cruft that we'd like to cleanup, etc.
• I needed a way to make an input recording file that I can mark certain inputs as ignored. In other words, different "types" of input recordings beyond just how they begin (savestate/poweron)

Additionally, I corrected our handling of unicode strings in the recording logging namespace, and switched the vast majority away from WX's file handling in favor of ghc::filesystem. The new file format implementation also moves away from C libraries in favor of the C++ standard lib.

For utf8 handling I referenced - http://utf8everywhere.org/
For binary file format best practices - https://fadden.com/tech/file-formats.html

This PR still likely needs some cleanup, but functionality it's decently tested (i can record/playback and accurately convert from V1). However, I wanted to put it up "early" to get feedback, mostly from @sonicfind as I know his upcoming MultiTap work may benefit from this (or be ruined if i made a mistake!)

[Warepire]

General suggestion for the file format: If you want maximum flexibility, binary is not the best choice for the header. How about a Yaml header + binary input data for each frame. Doesn't even need to be the same file if you don't want to mix the different types of data if you use something like tar and optionally zstd to compress it on the fly.

(I picked tar as an example because the basic version can be implemented in 100 lines of code or so if you don't need to handle special files)

[xTVaser]

That's a good point, I abandoned the idea of YAML for the entire file for performance reasons, but I like the idea for just the header.

On the subject of compression, it was something we talked about in the past and the verdict was that it doesn't really feel worth it. Hours and hours of recording takes up less space than a single PCSX2 save-state (which is compressed!) to put it in perspective.

[Warepire]

I didn't know if it would make sense or not which is why I specified compression as optional, and you proved that it doesn't make sense to compress. So that part can definitely be ignored.

[xTVaser]

Thought about the YAML change a bit more, it's problematic for just the header as well. While it would be more flexible, there are values within the header that get updated every frame, and since the YAML data is going to be variable size, we can't selectively update those values in-place.

I don't think we're sacrificing too much flexibility wise. No matter the format, new fields have to be handled using the version schema appropriately. While it is certainly a bit more cumbersome to work with the binary format compared to the alternative, it affords us some optimizations we need while still keeping things fairly organized/centralized.

[Warepire]

Updating in place can be done if you keep the data in a struct or something which you serialize to yaml as necessary. But if binary format overall is easier to manage in this situation, then I have nothing against the binary format.

[xTVaser]

We should disable the following codacy remark lint check:

It's apparently prone to false-positives (all the flagged ones here are) remarkjs/remark-lint#78

[xTVaser]

Reasonably confident with this, did the following tests:

• Confirmed there were no issues removing the following workaround in linux:

  pcsx2/pcsx2/Recording/NewRecordingFrame.cpp

  Lines 101 to 107 in 721253b

  	wxString path = m_filePicker->GetPath();
  	// wxWidget's removes the extension if it contains wildcards
  	// on wxGTK https://trac.wxwidgets.org/ticket/15285
  	if (!path.EndsWith(".p2m2"))
  	{
  	return wxString::Format("%s.p2m2", path);
  	}

• Created an input recording from power-on and from a savestate on master (legacy recordings)
  • Was able to play both back successfully. Each were converted while the originals were left in-tact.
• Created an input recording from power-on and from a savestate on this branch (use the new format from the beginning)
  • Both of these also worked fine.

[Warepire]

You can save a line (and possibly a reallocation) if you pass size when constructing output: std::wstring output(size);

[xTVaser]

Closing this PR, very out of date, especially with the migration to Qt -- and I've since realized I need to radically alter the file format to do more useful things anyway. This format still holds too true to the original V1 and would be useless for planned features.