Request Body schema for `/variables` POST is too broad

Nobody has claimed this yet.

Analyzing the variables API the following was noticed in `src/common/paths/variables.yml`

The POST request body is defined with a reference to `../../common/schemas/Variable.yml`.

This is the general `Variable` type that also includes properties such as `createdAt` and `updatedAt` which should intuitively not be part of a POST request. There are other suspect properties here. Furthermore this schema is also used to define the type returned from GET and so includes properties, which should be set on the server side, but which should not be available in a POST request.

After inspecting actual POST requests sent to the `/variables` endpoint by the UI it appears that only four properties are actually needed.

* `selected`
* `name`
* `arguments`
* `orgID`

Elsewhere it has been noted that request bodies have been defined in a schema following the pattern `PostRequest`, e.g. PostBucketRequest, or similar.

The request body schema for POST `/variables` should be different from the schema used with GET, should be identifiable with the token "Request" in its name and should probably be limited to these properties:

* `id`
* `selected`
* `name`
* `arguments`
* `orgID`

latest commit in local openapi:

```
commit 152e315e8ac269b268f1b8095cae1c83f65c261f (HEAD -> master, origin/master, origin/HEAD)
Author: Nick Stalter
Date: Mon Aug 1 11:38:12 2022 -0400

```

Start with src/common/paths/variables.yml and inspect the referenced ../../common/schemas/Variable.yml alongside the existing PostRequest schema pattern mentioned in the issue. Define a distinct request schema for POST /variables, limited to the properties identified in the issue, and update the endpoint reference while preserving the broader GET response schema.

Written by the indexing model from the issue text.