octoprint_compat: add webcam_rotation parameter

[zanhecht]

octoprint_compat: add webcam_rotation parameter
docs: document webcam_rotation parameter in configuration.md

Add webcam_rotation parameter to the [octoprint_compat] settings to allow specifying a rotation in degrees (0, 90, 180, 270) to match the [webcam] rotation parameter. Since a horizontal flip and a vertical flip combined are equivalent to a 180-degree rotation, this is implemented by setting flipH and flipV to true for a 180 degree rotation and setting those parameter plus rotate90 to true for a 270-degree rotation.

Re-submission of #592 in line with the contributing guidelines.

Signed-off-by: Zan Hecht [email protected]

[Arksine]

Hi. As per the discussion in the last PR, I don't think its a good idea to add this option. I understand that a 180 degree rotation is effectively a combination of a vertical and horizontal flip, but I'm not convinced that it is immediately apparent to users the since flip options rotate the image along different axes. I realize that the goal of this PR it to simplify configuration in some instances and provide an option similar to that in the [webcam] module, however in my experience introducing "alternate" configuration options tends to create more confusion, ie: "Which one do I use?"

Typically attempts to improve configuration involve deprecating old options. I considered this for octoprint_compat by replacing the "webcam" options with a webcam_name option similar to that in the [simplyprint] module. Ultimately I decided against this for two reasons:

1. I did not want to force existing users to reconfigure their [octoprint_compat] module.
2. I view the [octoprint_compat] module itself is a "necessary evil" to enable some level of compatibility with slicers. I would prefer not to maintain a compatibility layer with Octoprint's REST API, and my hope is that eventually slicers will implement extensions that use Moonraker's native APIs.. Unfortunately the existence of the compatibility module itself discourages this, thus it is my view that further changes to this module should be limited to essential changes (ie: bugfixes).

[Arksine]

As discussion seems to have concluded on this PR, I am closing it. Thanks.