Split the packages, publish releases from Gitea Actions, release 0.1.0

make deb now builds two packages: jarl-cli (the CLI, its completion and
the ACME hooks, no scripts) and jarl (the server), which depends on
jarl-cli of the same version.

Pushing a v* tag runs .gitea/workflows/release.yml: it tests, builds the
tarballs, the CLI for Linux, macOS and Windows (make cli-dist) and the
.debs for amd64 and arm64, then scripts/gitea-release.sh creates the
Gitea release and uploads the .debs to the Debian package registry, so
servers install and upgrade with apt. The stats package's inode lookup
is split by OS so the CLI builds for Windows.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

deploy/debian/control-jarl.in

@@ -0,0 +1,21 @@
+Package: jarl
+Version: @VERSION@
+Architecture: @ARCH@
+Maintainer: @MAINTAINER@
+Installed-Size: @SIZE@
+Depends: systemd, jarl-cli (= @VERSION@)
+Recommends: bind9 (>= 1:9.20)
+Section: net
+Priority: optional
+Description: web UI, REST API and CLI for managing a BIND 9 server
+ Jarl manages a BIND 9.20 server: zones, records, views, ACLs, TSIG keys
+ and options, through a web UI, a REST API and the jarl command line
+ client. Every change is validated, checked with named-checkconf and
+ loaded into named as one changeset that can be reverted. Users and API
+ tokens have fine-grained permissions, and every change is audited.
+ .
+ This package is the server: jarld (the daemon, as the systemd service
+ jarl) with its daily backup timer. The jarl CLI comes from jarl-cli,
+ which can also be installed on its own on other machines. jarld isn't
+ started on a first install: see /usr/share/doc/jarl/docs/install.md to
+ create the database and adopt the BIND configuration.