IOS: Leverage Kernel/EmulationKernel difference for passing System to most IOS devices.

[AdmiralCurtiss]

@leoetlino I assume you had something along these lines in mind over in #11743?

I've added a EmulationDevice interface that slots between the Device interface and the actual device classes that doesn't do anything but enforces that the IOS instance is an EmulationKernel instead of a plain Kernel. This allows all subclasses to know that they will only be constructed on an EmulationKernel, which allows them to safely access the m_ios reference as an EmulationKernel&. I think this looks quite nice and should have no runtime overhead.

[leoetlino]

I've only skimmed through the diff, but that looks like exactly what I had in mind - thanks for implementing this! Will give this a better look later this evening

[leoetlino]

lgtm

What's the plan for the core devices that always exist (e.g. ES and FS)? Add a Kernel::TryGetSystem() that returns a pointer instead of a reference?

[AdmiralCurtiss]

What's the plan for the core devices that always exist (e.g. ES and FS)? Add a Kernel::TryGetSystem() that returns a pointer instead of a reference?

I'm not entirely sure about this one yet. My initial idea was to split them into an ESDevice and an EmulationESDevice like Kernel/EmulationKernel but I'm not sure if that actually works well in practice. A TryGetSystem() or similar would work, yeah, but ideally it would be obvious at compiletime whether any given function is only for emulation or can also be called for NAND maintainance.