SWW_APPS: an app's Core Rule Set fixes apply only to the hostnames that serve it (closes #220)

Each app's fixes are one .conf file and one entry in apps. They apply
only while Inspect has set the app's transaction variable, such as
tx.app_gitea. SWW_APPS names each hostname's apps. A hostname gets only
its apps' fixes; while SWW_APPS is unset, every hostname gets every
app's fixes.

A hostname in SWW_APPS that is not a DNS name, such as *.example.com,
stops the start. Unset, SWW_APPS is logged at start as null; set
empty, as "".

Model: opus-5-5

docs/settings.md

@@ -255,6 +255,31 @@ the request first.
   a range. So does a directive that removes or changes rules as the file loads,
   such as `SecRuleRemoveById`, since none of the Core Rule Set's rules is loaded
   yet. It has no `_FILE` form.
+- `SWW_APPS` (default unset): the apps each hostname serves. A request gets the
+  fixes of its hostname's apps only (see "Attack detection" in
+  [`SPEC.md`](../SPEC.md)).
+    - Entries are separated by semicolons. Each is a hostname, a colon, then one
+      or more apps separated by commas, for example
+      `git.example.com:gitea;blog.example.com:wordpress`.
+    - The supported apps are:
+        - `drupal`;
+        - `gitea`;
+        - `mastodon`;
+        - `mediawiki`;
+        - `nextcloud`;
+        - `vaultwarden`;
+        - `wordpress`.
+    - The request's `Host` is matched by exact name, without its port and
+      without regard to case. There are no wildcards.
+    - A hostname not listed gets no app's fixes, so every rule checks it in
+      full. Set empty, `SWW_APPS` lists no hostname.
+    - Unset, every app's fixes apply to every hostname.
+    - Any of these mistakes stops the start:
+        - an unknown app;
+        - a hostname that is not a DNS name, such as `*.example.com`;
+        - a hostname listed twice;
+        - an app listed twice for one hostname;
+        - an entry without a colon.
 - `SWW_ERROR_BURST_THRESHOLD` (default `30`): the most refusals a client may get
   in a minute from a rule file, a trap path or the Core Rule Set, a count or
   `off`. The next one bans the client (see "Attack detection" in `SPEC.md`).