OpenAPI description needed for the service

To document (or test, expose and secure) the endpoints, an OpenAPI file should be created. Doing so would expose the weaknesses of the current interface (which one has to discover by trying to use it).
For example, the additional arguments are on the same level as the well-known `domain` and `problem` arguments, so you cannot say what is mandatory and what is optional.
Similarly, you would have tough time documenting the `result` element, because in context of `status: PENDING` it is a string/URL, and in context of `status: ok`, it is a structure. I recommend putting the URL to a distinctly different element outside of the `result` field. This is submitted as a separate issue https://github.com/AI-Planning/planning-as-a-service/issues/38

I had to capture the structure for my own sanity:
Package manifests:
https://github.com/jan-dolejsi/pddl-planning-service-client/blob/569c320e7d48812c3cbe04a02b9d4b81962130f6/src/PackagedPlanners.ts#L22
(note the uncertainty about the argument type `type: "file" | "int" | "categorical" // is "string" or "boolean" supported?` as well as the `categorical` choice `value` `type` - could that be a number? or a boolean?)

Returned payload:
https://github.com/jan-dolejsi/pddl-planning-service-client/blob/main/src/PlannerPackagePreviewService.ts#L125

Attached is the OpenAPI for the original `/solve` interface as well as a public subset the more detailed sync/async `/request` interface, which is how we expose the planner in our solutions.

[openapi_academia.zip](https://github.com/AI-Planning/planning-as-a-service/files/8813319/openapi_academia.zip)