Allow converting HFS+ to HFS+

[boredzo]

The disk image from http://macintoshgarden.org/apps/adobe-font-folio-110 presents an interesting case: It's an HFS+ volume on an ISO 9660 disc, but Disk Arbitration fails to notice the HFS+ portion and mounts the device as a simple device with no partitions.

Meanwhile, impluse finds the HFS+ volume just fine, and is happy to list it and extract select items, but refuses to convert it because it's already HFS+.

Maybe we should just allow this? It might enable accessing some HFS+ volumes that macOS, for whatever reason, is failing to parse correctly.

[boredzo]

This requires writing an ImpHFSPlusToImpHFSPlusConverter class, because the existing converter is written specifically to handle a source volume that is HFS (with all the volume structures that implies).

I wonder if this could be made so that the ImpSourceVolume subclasses abstract away the underlying details…

[boredzo]

No, that won't work because it's not just the volume structures, but also the catalog.

Theoretically an HFS+-to-HFS+ converter could just copy over the catalog verbatim.

[boredzo]

There's also the question of what to do about the surrounding partition map and other partitions (including the ISO 9660 region for images that have one). The more we copy over verbatim, the fewer things such a conversion might fix.

[boredzo]

There would also need to be an architectural change to support multiple converters and letting each one answer whether it can convert a source volume or not. ImpHFSToHFSPlusConverter would refuse an HFS+ volume, while a hypothetical ImpHFSPlusToHFSPlusConverter would take ti.

Currently, source volume validation happens in ImpHFSToHFSPlusConverter, and -[Impluse convert:] invokes that directly on the (currently correct) assumption that that's the only converter that is.

[boredzo]

We probably need to do that architectural support anyway for #10, MFS support.

[boredzo]

Currently, convert: sets up an HFS-to-HFS+ converter and then the converter uses ImpVolumeProbe to find volumes it can convert. Maybe that should be the other way round: convert: should use ImpVolumeProbe to find all the volumes on the disk, and each ImpSourceVolume subclass could have a method to return an array of converter classes. Or maybe a converter class for a particular destination format (or Nil if there's no such converter).

So convert: would use ImpVolumeProbe to find volumes; for each HFS volume, the probe would yield an ImpHFSSourceVolume, and for each HFS+ volume, the probe would yield an ImpHFSPlusSourceVolume. convert: would ask each source volume for converters for the (default/currently only) destination format of HFS+, and each source volume would return either ImpHFSToHFSPlusConverter or ImpHFSPlusToHFSPlusConverter (or ImpMFSToHFSPlusConverter if/after #10 happens).