CI: add setup gate job with workflow_dispatch target filtering and uncomment NetBSD/DragonFlyBSD jobs

[Xor-el]

Overview

Introduces a setup gating job that resolves the effective target list
exactly once and exposes it as a workflow output. Every other job gates
on that output, giving a single source of truth for which targets are
enabled. Adds workflow_dispatch support so any subset of targets can
be triggered ad-hoc from the Actions tab without editing the workflow
file. NetBSD and DragonFlyBSD jobs are promoted from commented-out
blocks to real jobs (still off by default via the gate).

---

setup Job — Target Gating

A new setup job runs first on ubuntu-latest and emits a single
enabled_targets output consumed by every downstream job.

• The default target list (DEFAULT) lives in exactly one place inside
  this job. To permanently disable a target, remove its ID from
  DEFAULT. Currently absent from DEFAULT (and therefore off by
  default):

  • netbsd — package CDN intermittently times out
  • dragonflybsd — FPC 3.2.x TLS broken; pure-Pascal DNS resolver bug

• On push / pull_request / schedule triggers there is no
  inputs context, so INPUT_TARGETS is empty and the job falls
  through to DEFAULT.

• workflow_dispatch with an empty textbox also sends an empty string
  (the declared default: is suppressed by GitHub in that case), so it
  too falls through to DEFAULT.

• When the user types a non-empty comma-separated list in the dispatch
  input, whitespace is stripped and that list overrides DEFAULT.

• The resolved list and its source (default vs workflow_dispatch input) are printed as a ::notice:: annotation in the Actions log.

---

workflow_dispatch Input

inputs:
  enabled_targets:
    description: >-
      Comma-separated list of targets to run (leave empty for default).
      Valid IDs: linux-x64, linux-arm64, windows-x64, macos-arm64,
      macos-x64, linux-arm32, freebsd, netbsd, dragonflybsd, solaris
    default: ""
    type: string

Leaving the field empty (or not using workflow_dispatch at all)
produces the same result as a normal push build.

---

Per-Job Gating Changes

native job

Each matrix entry gains an id field. A new Check if target is enabled step runs first, sets steps.gate.outputs.enabled, and all
subsequent steps are conditioned on steps.gate.outputs.enabled == 'true'. This keeps all five runners in the matrix (no dynamic matrix
generation needed) while still skipping the checkout and build steps for
disabled targets.

All other jobs (linux-arm32, freebsd, netbsd, dragonflybsd,solaris)

Each job gains:

needs: setup
if: contains(format(',{0},', needs.setup.outputs.enabled_targets), ',<id>,')

The format wrapper ensures clean comma-boundary matching so e.g.
linux-x64 cannot accidentally match linux-x64 inside linux-arm64.

---

NetBSD and DragonFlyBSD — Uncommented

Both jobs are promoted from commented-out YAML to real job definitions.
They retain their existing known-issue comments and are kept off by
default (absent from DEFAULT) via the gate rather than by being
commented out. This means their YAML is validated by GitHub on every
workflow parse, and they can be triggered on demand via workflow_dispatch
without any file edits.