Property grouping is wrong: token is under main, projectId is not a destination, issueDescription is advanced

## Problem

`io.kestra.plugin.gitlab.issues.Create` groups several properties under a category that does not
describe them.

| Property | Current group | Expected | Why |
|---|---|---|---|
| `token` | `main` | `connection` | It is the credential. `url` is already `connection`, so the two halves of reaching GitLab are split across two groups. |
| `projectId` | `main` | `destination` | It says *where* the issue goes. The equivalent in `plugin-github`, `repository`, is `destination`. |
| `issueDescription` | `advanced` | `main` | It is the issue body. `plugin-github`'s equivalent `body` is `main`. |
| `apiPath` | `advanced` | `connection` | It is part of the base URL of the instance, alongside `url`. |

### Expected behaviour

`url`, `apiPath` and `token` are `connection`; `projectId` is `destination`; `title` and
`issueDescription` are `main`.

### Actual behaviour

An access token is presented as an ordinary parameter next to the issue title, and the issue body is
hidden under advanced options.

### Why it matters

`$group` is what tells the UI which section to render a property under, and what any schema-driven
consumer reads to tell credentials apart from parameters. Kestra is building a form that configures a
ticketing system from a task's connection properties
(https://github.com/kestra-io/kestra-ee/issues/10859); GitLab would render with no credential field.

## Secondary question: is `issueId` the global id or the `iid`?

The `issueId` output is documented only as "Issue ID". GitLab issues have both a global `id` and a
per-project `iid` — the latter is the number users actually see and reference (`#42`). If the output
is the global id, there is no way to build the reference a human recognises. Worth confirming, and
documenting either way.