requesthandler: Add Canvas support

[exeldro]

Description

Add Canvas support

Motivation and Context

Scenes in not the main canvas are now not accessible

How Has This Been Tested?

using different obs-websocket clients, calling the new GetCanvasList and calling the other scene call with and without a canvas
Tested OS(s): Windows 11

Types of changes

• New request/event (non-breaking)

Checklist:

• I have read the Contributing Guidelines.
• All commit messages are properly formatted and commits squashed where appropriate.
• My code is not on master or a release/* branch.
• The code has been tested.
• I have included updates to all appropriate documentation.

[PatTheMav]

Canvases (at least per their original concept) are a data structure to allow OBS Studio as well as plugins to generate and access "outputs" that exist in the application. I'd be interested to learn what the use case for a websocket-based client would be to get direct access to this internal data object?

Conceptually a remote control client (what websockets is made for) should not futz around with canvases - it can interact with OBS (which then uses canvases to achieve the required result) or possibly with a plugin (which again might use a canvas to do so), but the fact that canvases exist is not something an external API should even know about.

[pwnyy]

Canvases (at least per their original concept) are a data structure to allow OBS Studio as well as plugins to generate and access "outputs" that exist in the application. I'd be interested to learn what the use case for a websocket-based client would be to get direct access to this internal data object?

Conceptually a remote control client (what websockets is made for) should not futz around with canvases - it can interact with OBS (which then uses canvases to achieve the required result) or possibly with a plugin (which again might use a canvas to do so), but the fact that canvases exist is not something an external API should even know about.

Adding canvas support seems rather important for applications that are communicating over the websocket server, to control and alter scenes, sources and filters on a different canvas. This would be especially true for those people that, for example were previously using a plugin to have a vertical "canvas" and with a third-party application that uses the websocket client alter/create/remove these scenes, sources or filters.

Currently this is not really possible anymore, as the plugin also switched over to the canvas system.

I can potentially see why you don't want the whole canvas object exposed, however a way to differentiate canvases with what scenes or sources are on which canvas and to be able to directly target these things is something that still should be considered. Same as maybe an optional parameter to target a specific canvas, if not set it will use the main canvas, to target things.
Being able to get a list of scenes and their sources etc. in each canvas would be needed in that regard as well, which at the very least this PR would provide

Maybe I'm misunderstanding why it wouldn't be a good idea tho.