Refactor "abstract" resource mapping

[zerocrates]

The abstract resource mapping is sort of a "reversed" abstract class: it contains essentially all the implementation and the concrete classes just pick and choose methods to call (the item mapping class calls xItem methods in the abstract, etc.)

I don't see a reason why this should be set up this way, when we already have a system for selecting which mapping classes to apply to a given type of import: we can simply have a concrete mapping class for items, one for item sets, one for media, and one for the generic all-resource options: then each typed import would use both the mapping class for its specific resource and the generic one, while the mixed resource import would use all 4.

At a first glance I don't see much if any interconnectedness to the various methods so it should be possible to do a pretty clean refactor here.