Add "custom type" defintions for protocol.json/protocol.md generation

[sid2934]

Description

This Pull Request hopes to propose a solution to an issue I was facing. Currently the protocol.json/md do not provided full type information for generating clients that call the OBS WebSocket server. Internally obs-websocket is build responses dynamically for a number of request/response properties. This means its flexible, but at the cost of usability when the API is fairly stable at this point.

Motivation and Context

The motivation here is to introduce light weight mechanism that will allow generators to create fully statically typed models for the request/response objects. This is the less invasive of the two options I considered since it does not modify any of the obs-websocket code, as all of the changes are in comments and the documentation generators only.

The alternative option is create the needed request/response property type models (likely header files) and enforce the use of statically typed objects throughout the code base. These new models work require the same/similar annotation to produce the proper protocol.json.

How Has This Been Tested?

Generators are working, no core changes to obs-websocket functionality

Tested OS(s):
Windows and MacOS

Types of changes

• Documentation change (a change to documentation pages)
• Other Enhancement (anything not applicable to what is listed)

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.

[sid2934]

A quick note outside of the PR description. While the pattern that I submitted with the current commits would work for my needs, I am not sure the formatting or location of the custom type comments are where you all would like.

My personal preferences would be to create the typed classes for the request/response property types, annotate those, and then use static types across the code base. That said that adds a degree of inflexibility that can be a challenge to keep up-to-date with changing models from the upstream project.

I am more than happy to make adjustments or change approach as you all see fit.