PD-type controllers: Allow for derivative action on either control error or on plant output

[geez0x1]

This is useful in some cases as it avoids a zero in the closed-loop transfer function and results in 40 dB/dec roll-off (for a PD applied to a fixed-output plant) as opposed to 20 dB/dec. Does seem to require higher gains for the same bandwidth (as the zero isn't there to 'push' the response up before the roll-off from the poles occurs), but doesn't saturate inputs as easily towards higher frequencies and doesn't suffer as much from digital control aspects such as discretisation and delays. Hence it is quite useful.

~~Current working branch: dev_ref_derivative~~: Merged into master

TODO:

• [x] Update PD+FF/comp controller
• [x] Update PD+FF/comp with inner-loop DOB controller
• [x] Update PD+FF/comp with OUTER-loop DOB controller
• [x] Update mask_PID_FFComp_OuterLoopDOB
• [x] Update design_DOB_controller()
• [x] Update get_controlled_closed_loop() (dependency of design_DOB_controller()): ~~Dox and header done, various control sections need updating.~~
• [x] tools testing: Done, found #74 in the process
• [x] updating simulink block masks to provide updated (text) arguments to various DOB tools: Update mask_PID_FFComp_OuterLoopDOB possibly -> OK
• [x] simulink block testing: PD, PD+inner-loop DOB, PD+outer-loop DOB: All work well
• [ ] updating unit test hashes?

[geez0x1]

@joernmalzahn : This work has now been merged into master. I still have issues with running Simulink unit tests, my computed hashes always differ. Before I close this, could you perhaps run them once to confirm all hashes are still valid? I've checked the models, and as the default setting for the derivative action is identical to before, the hashes should be the same.

However, some examples(and thus tests) have variable-step solvers, and I'm not sure what Simulink uses to base those decisions on. We could think of setting the examples/unit tests to fixed-step solvers.