feat: Extend plugin API to support transfer handlers

[mandelsoft]

What this PR does / why we need it

The OCM library already provides an extension point to provide transfer handlers
controlling the transport of component versions from one environment into another one.

A transfer handler controls:

• how to handle changes in component versions when re-transporting them
• how to resolve component references and whether they should be transported, also
• whether sources and resources should be transported by value or by reference.

So far, there were two implementations:

• a standard implementation working on the standard transfer options, like --recursive or --copy-resources
• a spiff++ based implementation based on the standard handler adding the capability to influence
  the behaviour based on a spiff script.

On the command line interface always the spiff handler was used which works like the standard handler if no script
is configured.

This PR adds three new features:

• it supports a hierarchical naming scheme to denote transfer handlers (like for download and upload handlers),
  which can be used un the command line to select and configure supported transfer handler types.
• it extends the Plugin API to support transfer handler. This way a plugin may implement the transfer handler interface to
  provide an arbitrary rule set controlling the transport process.
• A general configuration option for handlers allows for passing additional handler configuration

Similar to the uploaders and downloaders the naming scheme for transfer handlers looks as follows:

• ocm/<builtin handlers>: used for the already existing standard and spiff handlers.
  Additional handlers may now add themselves to appropriate names to be usable from the command line.
• plugin/' A dedicated handler maps plugin provided transfer handlers into the naming scheme.
  It uses the sub scheme <plugin name>[/<handler name>]. A plugin may provide multiple (named) handlers.

Which issue(s) this PR fixes

[fabianburth]

Since I've been struggling to see the plugin architecture since it is quite scattered throughout the library, is there documentation providing an overview?
Thus, the plugin implementer side including the role of the Plugin Descriptor and the plugin implementation support library (Plugin Programming Interface (PPI)) or a raw command implementation, as well as the plugin caller side including Plugin Adapter , the registrations (RegisterExtensions() / RegistrationHandler()) and the individual extension point specific plugin packages AND how all these parts fit together.

[fabianburth]

Suggested change

	func NewOUpdateVersionDecision(desc string, h ComponentReferenceQuestionFunc, labels ...string) DecisionHandler {
	func NewUpdateVersionDecision(desc string, h ComponentReferenceQuestionFunc, labels ...string) DecisionHandler {

typo

[mandelsoft]

no, duplicate function with typo in name. (removed)

[fabianburth]

Suggested change

	func NewTransferversionDecision(desc string, h ComponentReferenceQuestionFunc, labels ...string) DecisionHandler {
	func NewTransferVersionDecision(desc string, h ComponentReferenceQuestionFunc, labels ...string) DecisionHandler {

typo

[mandelsoft]

done

[fabianburth]

I feel like it is confusing that the type configOption is not the type that's supposed to be implementing the interface ConfigOption.

[mandelsoft]

It is supposed as option (like the other structs). In this case an option to feed the ConfigOption interface.

[mandelsoft]

Renamed to ConfigOptionConsumer and added more docu.