Status: PluginGroups for other reusable entities

[apirogov]

Possible candidates include:

harvester:

• Done?
  A harvester plugin extracts metadata and returns a (partial) metadata object. This would be very useful for reuse in packers that work with the same kinds of data.

bag:

• Done ?
  A generalized "bag" of functionality that is not worthy to be versioned separately, like a module, only that we put it in a class. Uses:

• Bag of types (for hints that are not schemas)
• Bag of helper functions

ensure that bags cannot have any further inheritance, because that would be insane.

mapping:

• Done?

A mapping plugin defines a set of mappings between versioned schema plugins (registering each single mapping as an entry point is nonsense because the number of mappings is quadratic in the number of existing schemas, so let's group them).
Mappings are needed for cases where transformation is not implicit (i.e. not taken care of by schema inheritance, and not taken care of by semantic versioning, e.g. mapping between major versions are necessary).

The mapping interface should provide automatic mapping path between two schemas, if possible ("(schema,mapping) graph search")
we will need this when starting to work on searchability and interoperability of metadata.

As it is not possible to have two versions of the same plugin installed (same entry point), a workaround could be that a mapping simply brings the schemas it maps in the declared version and uses them for parsing and serializing.

Probably mapping plugins never need major version increments and only should do minor increments when adding new mappings.

CLI:

• Done?

see #9