[MINOR] Unclear return argument `success` from `optimizerFORCES`

[AndreasHempel]

The documentation for optimizerFORCES shows a second return argument success which is not used consistently throughout. Some problems are handled by throwing an error(...) (which leaves success unset), others use disp to show a message and set success = 0.

Since success is initialized as 1 I suspect potential for misreporting success, e.g. in cases where no error is thrown but success is not re-set or if it is set multiple times.

Due to the high complexity in optimizerFORCES I find it preferable to throw an error as soon as a game-breaking issue occurs, e.g. a model incompatible with FORCES Pro. success should exactly mirror the return argument of generateCode in FORCES Pro.

[GianUlli]

What you described is already implemented. success is the result of combining all of the success outputs of the internal solvers (combined using logical AND). However, if one of the internal solvers couldn't be generated, an error is thrown by optimizerFORCES. disp was only used for the case that the user decided to cancel code generation after being asked about binary variables. I fixed that with commit b70630f. Instead of using disp to display the error message and returning an empty object, an actual error is thrown.

So, now, if optimizerFORCES returns a object (hence no error was thrown), success is always 1. It could be removed as output argument because it doesn't help the user.