feat(TaskProcessing): Allow defining custom task types

[bigcat88]

Conceptually, I would say the new task type should be independent from the provider. E.g. one app could register multiple providers for the same custom task type.

Will this implementation be enough at this stage? This does not require creating a new table, and is simpler from a API point of view, IMHO.

[bigcat88]

import contextlib
from os import environ
from pathlib import Path

import nc_py_api

environ["APP_ID"] = "nc_py_api"
environ["APP_VERSION"] = "1.0.0"
environ["APP_SECRET"] = "12345"

if __name__ == "__main__":
    nc = nc_py_api.NextcloudApp(nextcloud_url="http://nextcloud.local")
    nc.set_user("admin")

    nc.providers.task_processing.register(
        "visionatrix",
        "SDXL Lighting",
        "visionatrix:sdxl_lighting",
        {
            "id": "visionatrix:sdxl_lighting",
            "name": "SDXL Lighting",
            "description": "Fast Image Generation",
            "input_shape": {
                "prompt": {
                    "name": "prompt",
                    "description": "Prompt",
                    "type": 1,  # Text
                }
            },
            "output_shape": {
                "image": {
                    "name": "image",
                    "description": "Image",
                    "type": 2,  # Image
                }
            }
        }
    )
    s1 = nc.ocs(
        "POST",
        "/ocs/v2.php/taskprocessing/schedule",
        json={
            "input": {"prompt": "Star"},
            "type": "visionatrix:sdxl_lighting",
            "appId": "nc_py_api",
        }
    )
    print(s1)

    my_task = nc.providers.task_processing.next_task(["visionatrix"], ["visionatrix:sdxl_lighting"])
    print(my_task)

Description of idea(that is in this PR): if one ExApp provides multiple custom_task_types for each custom task_type it calls "Register Provider" (as anyway "Optional Shapes" are binded to Provider struct)

I am still in process of reviewing and learning how to use our new API..

[marcelklehr]

Will this implementation be enough at this stage?

I'm uncertain on this. think the goal of ExApps was to have stable APIs. Having this one in a half baked state does not contribute to that goal. On the other hand it may be possible to extend this implementation in the future. But then I don't see when we would do that. IMO it would be good to have this implemented properly, but I defer to @julien-nc