MacroPreprocessor: resolve Button type inputs

[imagejan]

When calling a command from a macro (with an option string), we usually don't want to show a UI dialog.

If the called command contains inputs of type org.scijava.widget.Button, we resolve these without setting them, as we assume that buttons and their callbacks provide some interactivity that is not required when running from macro.

See the closed PR #239 for some discussion.

---

I would have liked to respect a required={false,true} annotation for the Button input, but since Button extends Optional, isRequired() will always resolve to false, see also:

https://github.com/scijava/scijava-common/blob/46ca0d04c5c86eeb51f9daa9f130b0d7c8decd65/src/main/java/org/scijava/command/CommandModuleItem.java#L102-L106

---

I hope that this solution - while being a bit hacky - is less intrusive than #239, but still meets the requirements of the affected projects.

(/cc @frauzufall @NicoKiaru @tischi @romainGuiet @uschmidt83 @tferr)

Note 1: While in full-fledged scripting languages, you can always call commandService.run("command",false, ...) to avoid the automatic command preprocessing (and hence display of dialogs), this option doesn't exist in an IJ1 macro run("...") call.

Note 2: This pull request still allows commands whose dialog box is nothing else than a button to show a dialog box when invoked from the UI (scenario 1 in this comment by @ctrueden).

Note 3: I tried to add a test for this behavior in 401cb9c, but it's not headless, as it seems this issue only occurs when running from a macro with the UI displayed. In addition, we still cannot distinguish between macro calls with and without option string (run("Test Command") vs. run("Test Command", ""), see also scijava/scijava-common#317 (comment)).

[imagejan]

See #239 (comment), thanks @biovoxxel for testing!

@hinerm @ctrueden is there any chance we can get this merged and released soon?