The default systemd service files `clamav-freshclam` and `clamav-daemon`
(at least as installed in Arch Linux) do not contain any Sandboxing
options configured. Therefore, the service units are marked as `UNSAFE`
when `systemd-analyze security`[1] is run.

```
➜  ~ systemd-analyze security
UNIT                                 EXPOSURE PREDICATE HAPPY
..
clamav-daemon.service                     9.6 UNSAFE    😨
clamav-freshclam.service                  9.6 UNSAFE    😨
..
```

By including some basic security options[2], we can increase the
security level of the services - even if only a little bit - from
systemd's perspective.

For the daemon, I have used `ProtectSystem` and `ProtectHome` directives
to make the filesystem read-only - which should be okay when scanning
files. However, we have to make an exception for the log path using
`ReadWritePaths`. Additionally, this configuration would interfere with
the `--remove` option if the user chooses to auto-remove infected files.

Other options protect sysconfig, kernel modules, and the hardware clock.

Adverse effects are less pronounced if we apply similar configuration to
freshclam service - which ostensibly only updates a specific set of
files on disk. I referred to the Installation manual[3] to ascertain the
default file path to which fresh databases are downloaded.

With all these changes applied, the result of `systemd-analyze security`
looks like this:

```
➜  ~ systemd-analyze security
UNIT                                 EXPOSURE PREDICATE HAPPY
..
clamav-daemon.service                     7.8 EXPOSED   🙁
clamav-freshclam.service                  7.8 EXPOSED   🙁
..
```

While this seems like a definite improvement, we need to take user
experience, distribution-specific defaults, and best-practices (as
determined by ClamAV itself) to ensure that this changeset is valid.

[1] https://www.freedesktop.org/software/systemd/man/systemd-analyze.html
[2] https://www.freedesktop.org/software/systemd/man/systemd.exec.html
[3] https://docs.clamav.net/manual/Installing/Packages.html

In systemd unit files, I had missed some paths to commands that are
potentially executed in response to events. These commands are arbitrary
and configurable in clamd.conf and freshclam.conf.

Each of these options invoke an appropriate path to a configured
executable when - for example - a scan is complete or signature update
fails. In order for these executables to run, systemd should allow it.
It is necessary to add these paths to `ExecPaths` in systemd service
unit files.

This change adds comments instructing users and administrators how to do
that and generally helps make sense of the defaults.

- Plus some formatting changes

Harden ClamAV OnAccess service systemd unit file.

- Removed default move options to be consistent with the behaviour of
  the rest of the service files
- Added hardening parameters for service
- Added Reload and Stop signals for graceful reload and stop

This commit includes four changes:

1. Wait for clamd process using `--wait` and `--ping` switches instead
   of using a bash test for the presence of clamd.ctl socket
2. Use the PreStart directive to create log and quarantine directories
3. Add shared library path to ExecPaths allow-list
4. Add quarantine directory path to ReadWritePaths allow-list

- Add LogsDirectory= and ConfigurationDirectory= directives to the
  service files. This creates the log directory under /var/log and the
  configuration directory under /etc as specified in the unit file.
- Add LogsDirectory path to ReadWritePaths=
- Add /run and /var/run to ReadWritePaths=
- Add shared library path to ReadWritePaths=
- Add Alias to all three services

Known Issues:
- Terminating ClamOnAcc service is really slow and times out. SIGKILL
  takes over where SIGTERM fails to stop the process
- For ClamOnAcc to function effectively on files in $HOME, it needs the
  --fdpass switch
- The PIDFILE and Lockfile paths for services are not managed by Systemd
  yet.

Service user:
Added explicit user and group settings for service files. Clamd and
Freshclam now run as clamav user. Per documentation, the service forks
off process that runs as user specfied in the config. This change makes
that explicit.

Clamonacc still runs as root since it needs to access files that are not
owned by the default clamav user. An alternative approach is to use the
--fdpass to pass the file descriptor perms to Clamd instead of having to
stream the entire file.

Other changes:
- [gen] Added explicit service types. Forking type for ClamD failed even
  without foreground switch. So the service runs as a simple daemon.
- [doc] Updated comment strings to make them concise and unambiguous.
- [sec] Added a safer permission mode for quarantine directory.
- [sec] Added several new security settings to protect the system. Since
  unknown settings are safely ignored by older versions of SystemD, the
  settings should automatically apply when SystemD version is bumped.
- [sec] Added new network security settings. Clamd and OnAcc are not
   allowed to use the networkr; only Freshclam is.
- [sec] Added restrictions to several system calls and Linux
  capabilities

TODO / Known issues:
- PreStart tasks need root user access - for example, to create the
  quarantine directory. The current approach is unreliable.
- Some settings such as PrivateUsers=yes break the service file.
- We need CMAKE/Automake substitution strings to add (multi-arch and
  arch dependent) LIBDIR to certain settings.
- ExecPaths and ReadWritePaths need locking down.
- Parameterize DATADIR - e.g. /var/log/quarantine

LogsDirectory specified explicitly as such is automatically configured
to be writable by systemD. So it need not be explicitly specified under
ReadWritePaths.

Specify RuntimeDirectory for clamav services `/run/clamav` to make
PIDFiles writeable.

The RuntimeDirectory ownership is changed by SystemD to match the `User`
and `Group` specified in the service unit files. ClamOnAccess runs as
root and therefore would clobber the ownership of these directories set
by other services in the family. For this reason, until a better
approach is available, RuntimeDirectory and LogsDirectory are not
managed by SystemD for ClomOnAccess service.