Add Stream API to INTV.Core's ROM interfaces

[intvsteve]

The Rom base class presently only exposes a file-oriented API for creating ROM instances. There is a great deal of infrastructure built around this, including the Memo-based caches.

When unit tests were created, a great deal of effort was required to work around the limitations of using a Portable Class Library, which requires an IStorageAccess interface, as direct access to file system APIs is not available.

As work on archive support progresses, it's become clear that exposing a Stream-based API would be immensely useful - and perhaps would be a substantial simplification, if it's not going to be an insane amount of work.

To undertake this requires assessing how much work is required to curb the reliance on IStorageAccess, or at least allow the Memo system some greater flexibility in terms of decoupling it from IStorageAccess.

An alternative would be to extend the existing IStorageAccess implementation to instead have awareness of archives and render them essentially invisible to INTV.Core.

Perhaps both can be done, in that basic ROM format identification can be achieved purely via a Stream API and sidestep the memo system.

[intvsteve]

There is currently work underway that has added ROM format identification via System.IO.Stream.

In all practical purposes, actual usage of ROMs themselves requires them to be distinct on-disk entities:

• all ROM conversion tools are command-line tools that operate on file system files
• emulators operate using disk-based files

Perhaps tweaking the memo system to accept a 'name' and a stream would be another way to approach things. FileStreams would pass the file path (perhaps normalized in some way), while resource-based approaches could pass the resource name and the stream.

That could possibly remove the complexity of all of the quasi-storage-access scheme work in the test code, which is essentially doing what I just described. :P