GC/Wii filesystem internals shouldn't be exposed to other classes.
This change isn't especially useful by itself, but it opens up the
way for some neat stuff in the following commits.
By removing mutable state in VolumeWiiCrypted, this change makes
partition-related code simpler. It also gets rid of other ugly things,
like ISOProperties's "over 9000" loop that creates a list of
partitions by trying possible combinations, and DiscScrubber's
volume swapping that recreates the entire volume when it needs to
change partition.
Advantages:
* Simpler code in general
* No extra volume objects created
* Now actually notices if the disc or partition gets
changed while the core is running
* No longer picks up on disc access done by the GUI
(it used to do so as long as the core was running)
* Gets rid of a Core dependency in DiscIO
There are two performance disadvantages:
* FileMonitor is now a bit slower when used with VolumeDirectory
because FileMonitor now always uses the FileSystemGCWii code
for finding filenames instead of VolumeDirectory finding the
filename on its own and directly hooking into FileMonitor.
But this isn't such a big deal, because it's happening on the
DVD thread, and my currently unmerged file system PR will make
FileSystemGCWii's file finding code about as fast as
VolumeDirectory's.
* FileMonitor's creation of the file system object is now
done on the CPU thread instead of the DVD thread, and
it will be done even if FileMonitor logging is disabled.
This will be fixed in the next commit.
Rather than rely on the developer to do the right thing,
just make the default behavior safely deallocate resources.
If shared semantics are ever needed in the future, the
constructor that takes a unique_ptr for shared_ptr can
be used.
spycrab