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

Overview
--------
Introduces a setup gating job that resolves the effective target list
exactly once and exposes it as a workflow output. Every downstream 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 (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) and also falls through.
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 are printed as a notice annotation.


workflow_dispatch Input
-----------------------
A single enabled_targets text input accepts a comma-separated list of
target IDs. Valid IDs:
  linux-x64, linux-arm64, windows-x64, macos-arm64, macos-x64,
  linux-arm32, freebsd, netbsd, dragonflybsd, solaris

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 that output. This keeps all five
  runners in the matrix while skipping checkout and build for disabled
  targets without dynamic matrix generation.

All other jobs (linux-arm32, freebsd, netbsd, dragonflybsd, solaris):
  Each job gains needs: setup and an if: condition using
  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 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. Their YAML is now validated by GitHub on every workflow
parse, and they can be triggered on demand via workflow_dispatch without
any file edits.

Author: Xor-el