Start defining Inversion of Control: let parts of Moodle govern how to do merge operations

[jpahullo]

Start using Moodle core API named component_class_callback (or similar). It’s also common for Moodle Workplace.

The idea:

1. define flow for this plugin, while a merging request is being processed. This would redefine the current implementation of the method merge()
2. Define callbacks necessary to implement for parts of the Moodle (plugins, Moodle components, etc)
3. Implement current merge() method following this flow and callbacks.
4. Define a default pseudo component from this plugin, to process any Moodle table not being processed.

At the beginning, only the default pseudo component will treat all tables lime currently it does.

The idea is to sepparate merging actions per plugin and Moodle components to be self-contained. For instance: quiz callback would treat any logic behind merging two users, updating database records, executing php processes to normalize users records, etc.

The deault pseudo component will have to:

1. Process any table not processed by any other callback.
2. Perform standard actions: update records, delete records, etc.

Callbacks should cover:

1. List tables processed by this plugin/component
2. Give a plugin/component name
3. List tables that plugin/component requires to omit its normal processing. Tables are left with no changes.
4. List of logs of actions being done. Also, the start time and end time.
5. List of actions for possible rollback, if necessary.

[jpahullo]

One of this inversion of control should be also implementing #254