Eliminate initializers in favor of only callbacks

[ctrueden]

As proposed by @Stefan-Posch on imagej-devel, we may be able to get rid of the concept of module initialization completely, in favor of only callbacks. When a preprocessor populates a parameter value, its callback is called.

Potential obstacles:

• At the moment, callbacks only happen when the InputHarvester UI changes a value, not when Module#setInput is called. This is not necessarily intuitive though—we would change that in order to switch to only callbacks.
• If a parameter value needs to be derived from application state via service method calls, the callback would have to go on the relevant service(s). And in practice, those service values would never change beyond initially being set. But that wouldn't really hurt anything.
• If a "secondary" parameter value needs to be derived from multiple "primary" parameter values, each of those primary parameters would need a callback that includes a recalculation of the secondary parameter value. That is also fine, though.
• Chaining callbacks is not currently supported. That is, if a "tertiary" parameter is computed from a secondary parameter which is itself computed from a primary parameter, the primary parameter's callback would set the secondary parameter value directly, thus not triggering the secondary parameter's callback. It would be the programmer's responsibility to keep track of their "transitive parameter dependencies"—e.g., in the earlier example, the primary parameter's callback would need to update both the secondary and tertiary values.

[ctrueden]

If we do this, it would make #180 moot.

[adaerr]

It seems to me that initializers and callbacks can have very different
jobs. I have a plugin for example whose initializer performs a rough
but involved image analysis in order to initialize the parameter
values to sensible guesses. The callbacks do none of this, suppose
that the user knows what she is typing, and merely take care of
updating an overlay. In the case at hand the initializer is a global
one declared in @plugin, but the point is that for the simple cases of
non-dynamic Commands (regarding parameter types/numbers), the
distinction between initializer and callback is quite usefull, and
would have to be coded by hand if initializers were merged into
callbacks.

Maybe I got something wrong about the proposal, I just react because
it reminds be a bit of the implementation difference of previewable
plugins between IJ1 and IJ2: IJ1 chose to avoid a separate preview()
method in favor of overloading run(), but I like the finer IJ2
granularity much better because my plugin is not doing quite the same
thing for a preview update as for the final run, and some superfluous
dispatching code is avoided.

[ctrueden]

@adaerr Do you think it would be sufficient to keep the single global initializer, while getting rid of the parameter-specific initializers?

[adaerr]

@ctrueden Yes, that sounds good. The global initializer seems more general than parameter-specific initializers anyway (the latter can always be concatenated into one global initializer). From a callback programming point of view it seems interesting in my eyes to be able to suppose that all parameters have already been populated, and that is achieved just as well by a global initializer.