Document required token permissions for each bridge target - #1632

Bridges authenticate against their platform with a token, but neither the
usage documentation nor the "git bug bridge new" help text told users which
scopes/permissions each token must grant, nor that some targets need no
token at all.

Add a "Tokens and required permissions" section to doc/usage/third-party.md
covering each supported bridge:

- GitHub: classic PATs only (fine-grained 'github_pat_' tokens are rejected
  by the input validator), 'public_repo' scope for public repositories and
  'repo' for private ones; no permission for code, branches or pull
  requests is used.
- GitLab: personal access token with the 'api' scope (or 'read_api' for
  pull-only usage) must be created on the target instance, and the token
  owner needs read access to the project (at least 'Developer' role to
  push).
- Jira: the token (Cloud or Data Center/Server 8.+) authenticates as the
  user, so the account itself needs permission to view the project and to
  create, comment on, edit and transition issues; older servers fall back
  to username/password session authentication.
- Launchpad: no token required, the 'launchpad-preview' bridge only
  queries the public Launchpad API.

The required permissions were derived from the API operations each bridge
actually performs (issue listing, comment/label/status events on import;
issue creation, comments, labels and status changes on export).

Also update the examples in "git bug bridge new" with per-target permission
notes and fix two pre-existing issues found along the way: a missing line
continuation in the GitHub example (which made the command invalid) and the
GitLab example pointing at a github.com URL. The man page and markdown CLI
documentation were regenerated from the updated command definition.

Finally, correct the credentials section of doc/design/bridges/jira.md,
which claimed Jira does not support user API tokens and that the bridge
requires username/password; the bridge has supported API-token (Basic
auth) credentials for a while and both mechanisms are documented with the
permissions the underlying account needs.