Remove alwaysretrieve attribute to the "interface" tag/implement a new command RETRWRP

But note also #12 !! here we want to deprecate SELWRP (and by extension, also the not yet implemented RETRWRP).

This may seem illogical, but we want to allow for the old way of using SELWRP to still work if the new config style is not used. But at least we want to get rid of the alwaysretrieve attribute! So this seems to be a sensible compromise, have one complete manual way that is able to express everything via the UI, and a preferred way to use an action based configuration (in case we really need the "in" action as described in #12, we would also need to come up with yet another command, e.g. SBMTWRP that would express a "submit only, but no retrieving" property for a single request)

If we want to better preserve backward compatibility, we may also be able to do the following:

For the old configuration, just do as it was before: allow for SELWRP and alwaysretrieve attribute.

For the "new" configuration, there is no alwaysretrieve attribute. But we'll add another case where we explicitly allow a "manual" mode, that gives rise to the SELWRP, RETRWRP and SUBMTWRP commands to do everything by hand.

as said in #12, we think that we need to "in only" wrappers, and therefore also no SUBMTWRP command...

I agree on that. Usually retrieveCurrentStatus(...) is only used to fill in form values when the page is shown the first time (or the data has been changed by other handlers).

If retrieveCurrentStatus(...) should do nothing in certain situations, this should be reflected in the code of the IHandler and not in the configuration file.

I have now switched sides again on two points :-)

* Currently I think to implement also the <in> handlers, and also the SUBMTWRP command. While it is correct that it would always be possible to implement a handler with a "empty" retrieveCurrentStatus() method, I still think it is easier to be able to handle this situation with a configuration, instead of having to e.g. derive from an existing handler (and therefor also a new wrapper is needed) just to overwrite an already existing retreiveCurrentStatus() method to do... nothing :-) Either way, it won't take much time to also implement it, so we could just do it.

* I also think that removing the alwaysretrieve attribute is the right way to go. This WILL break backward compatibility, but it will allow to share the same IWrapperConfig object regardless of using "manual" mode or action based.

OK, this is done in my tree (and I will commit to the trunk ASAP):

1) alwaysretrieve is GONE. Well, there goes backward compatibility. I will gladly explain why this is the right thing to do if the question comes up...

2) I implemented two new <pfx:command>s: RETONLY and SUBONLY for handlers that should only call retrieveCurrentStatus() and those that should only call handleSubmittedData(). While not sure about the importance of SUBONLY, RETONLY will play the role of "alwaysretrieve", only under control from the caller.

we need to solve #27, and according to the decision we will be able to reduce our command set to 2 commands, one for listing the wrappers to call handleSubmittedData() and one for all the wrappers to call retrieveCurrentStatus() on (in this case, the two sets need not be disjunct)

OK, after #27 is decided upon, I reduced the "manual" case of selecting wrappers to two commands: SUBWRP and RETRWRP. These lists are NOT mutally exclusive (because of #27) - just list any wrappers that should handle submitted Data in the SUBWRP commands, and all wrappers who should update their form data via a call to retrieveCurrentStatus afterwards in the RETRWRP commands.

SELWRP is still there (deprecated) and behaves exactly the same as SUBWRP (so it changed it's behaviour, but as we think without consequences in 99% of the cases)