simple start, wrap anchor registration into plugin system, use miniupnpd as an example.

use registerAnchor() to register new anchors for pf into the main firewall script, we've hooked head/tail options and the different anchor types.
anchorToText() will extract the registered anchors back for the specified types and place in the script (head/tail) in text format for pf.

our new codebase was already hooked using legacy_bindings.inc, no additional includes needed to construct \OPNsense\Firewall\Plugin().

(ipsec, psk) writeout base64 instead of plain text, interpret "any" in the process, closes https://github.com/opnsense/core/issues/1205

(openvpn client export) add X-Content-Type-Options: nosniff header, closes https://github.com/opnsense/core/issues/1204

Uh, oh: the keys are not purged on factory reset.  Since we
now store the explicit host key file names in the config,
it's better to stop writing keys to /usr/local/etc/ssh and
just keep the backup where it was.  It's fully compatible
with our approach.

While there, remove the need to softcode commands in variables
as this was done to migrate from base OpenSSH to ports OpenSSH,
which was done in 2015.

I pulled this from the attic, but it makes no sense.  ;)

The rules edit page can do it, but it was not picked up
by the actual firewall rules...

Revert "(sshd) add HostKey to sshd_config to force available hostkeys. closes https://github.com/opnsense/core/issues/1200"

This reverts commit 4e83616c.

We need more input from the reporter, nobody has ran into this error
as far as I could see, testing was ok, and when OpenSSH switches
to the next version this will automatically align itself...

Fix a few style errors while there.

(sshd) add HostKey to sshd_config to force available hostkeys. closes https://github.com/opnsense/core/issues/1200

Now that we have a plist it's easier to review/preview changes.
Can finally tackle the src/opnsense/contrib mess in a sensible
way with this and since we do not rely on mount/umount anymore.

When we build packages, we want to know if something is wrong.
For now, only use it in the upgrade path, not sure how to
to distinguish if a user or the build system is running the
package build.

Transition away from making the internals known, so rework
the whole tree.mk to expand better to dynamic destinations.