Property grouping is wrong: projectKey is a connection property, summary and description are advanced

## Problem

Jira tasks group several properties under a category that does not describe them.

| Property | Current group | Expected | Why |
|---|---|---|---|
| `projectKey` | `connection` | `destination` | It says *where* the issue goes, not how to reach Jira. The direct equivalent in `plugin-github`, `repository`, is `destination`. |
| `summary` | `advanced` | `main` | It is the issue title — the most primary field there is. |
| `description` | `advanced` | `main` | Same. |
| `username` | `connection`, marked secret | `connection`, not secret | It is an account email. `plugin-github`'s equivalent `login` is not marked secret. |

As a result `issues.Create` has **no properties in the `main` group at all** — everything is either
`connection` or `advanced`.

### Expected behaviour

`baseUrl` and the credentials are `connection`, `projectKey` is `destination`, and `summary` /
`description` are `main`.

### Actual behaviour

The primary content fields are hidden under advanced, the project key is presented as part of the
connection, and a non-secret email is masked as a secret.

### Related: shared properties leak onto tasks that cannot use them

`issues.CreateComment` **requires** `projectKey` and also exposes `summary`, `description`,
`labels` and `issueTypeId` — none of which apply to adding a comment. `issues.UpdateFields` has the
same problem. This is likely the same root as the grouping: one base class contributing all fields to
every task. Splitting it would fix both, but the grouping fix is worth doing on its own if that is
too large.

### 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.

Related: https://github.com/kestra-io/plugin-jira/issues/101 (these tasks also return no outputs).