Support implementing and discovering extra plugin-based functionality

[petri]

(Background: #27 turned into discussion about how plugins could implement extra functionality, and how they could make it discoverable by end users. To continue that under an issue with title actually reflecting the topic, I've summarised the discussion here.)

The issue is that for example, GnuCash apparently only supports CREDIT / DEBIT transaction types, while the modern OFX standard specifies a whole bunch of them (seventeen, I counted). So, for use cases involving GnuCash, limiting/reducing the transaction types to those two would be a desirable, whereas for other use cases transaction types should be kept as-is.

Such extra functionality can of course be made 'discoverable' by plugin authors simply by documenting the plugins well. But that forces users to do a lot of work - browsing through all plugins to figure out what they can do. Given that ofxstatement is already capable of listing all available plugins, it would be useful for end users to be able to also list those plugins that provide some particular capability, such as filtering, or reducing the transaction types for GnuCash compatibility.

Or perhaps it would be sufficient if ofxstatement list-plugins would list, in addition to plugin names/labels, also some extra per-plugin description, that plugin authors could use to advertise the plugin capabilities?

@kedder summarized his thoughts:

I would like to leave such features and variances in behaviour to plugins themselves, via their private configuration options. We can invest some effort into making supported configuration options more discoverable by users, but I'd like to have it in informal way (e.g. as docstring), rather than formal (e.g. configuration schemas, interfaces, etc), because complexity of formal approach seems too high for the purpose.

Also, @MirkoDziadzka suggested an additional filter phase for ofxstatement:

As I understand them, plugins are more about converting an arbitrary input to OFX. Some of them are doing filtering. For example, I contributed stuff to merge some lines on some credit card statements. This was probably not the right place to do this but the only place I could added this back then.

Maybe a better place would be an additional OFX filter phase, where filter plugins can be registered to work on the OFX data and rewrite them before the output. This would make these features orthogonal to the input parsing and it would be possible to add an 'gnucash' filter which rewrites all the stuff that gnucash don't like.