This moves most of the code into a standalone (at least in principle)
"http_frontend" role and invokes it from the main LOCKSS role.

This creates a service that listens on (by default) port 80 and maps
LOCKSS's many Web interfaces, each listening on a different port, to
paths under a single base. For example:

    http://lockss.test/crawler -> http://lockss.test:24631

This is not ready for production. The remaining tasks are as follows:

- Turn the front-end into a proper Docker image and service. (It should
  include a health check.)

- Merge the lockss-config-frontend into the main lockss role.

- Remove from the firewall rules access to the other administrative
  ports that are now accessed through this.

- Document the front-end paths. Or, better yet, write a landing page
  that lists them all.

It's too slow to be worthwhile.

As I noted in an earlier commit, restricting Docker's ingress traffic is
more complicated than adding a few rules to the filter table's INPUT
chain. I had thought that relying on LOCKSS's "LOCKSS_ACCESS_SUBNET"
variable would be sufficient; unfortunately, that is not the case:
LOCKSS sees all of its traffic as coming from the Docker overlay network
(by default, 10.0.0.0/8), regardless of its true origin.

Fortunately for us, Docker provides us with a chain, DOCKER-USER, called
by Docker's rules from the FORWARD chain in the filter table, that is
suitable for filtering Docker's ingress traffic.

Accordingly, this commit:

- Removes the misleadingly ineffective 'lockss_trusted_ips' variable and
  provides new variables 'lockss_network_ips' and 'lockss_admin_ips'.

- Replaces ufw or firewalld with ferm. Neither ufw nor firewalld is
  capable of satisfying this use case without employing significant
  violence; ferm is elegant and has beautiful configuration files.
  Beauty over bloodshed.

- Adds tasks to configure a local firewall that denies inbound and
  forwarded traffic by default, permits ssh from anywhere, and permits
  access to LOCKSS's data and configuration ports from
  'lockss_network_ips' and 'lockss_admin_ips' respectively.

  Said firewall cooperates with Docker: Docker and the firewall can be
  started in any order, and restarting either preserves rules created by
  the other.

                                *  *  *

I got the suggestion of using ferm for this, as well as the bulk of the
Docker-related rules, from a blog post: Ben Chavet, Convincing Docker
and Iptables to Play Nicely, Aug. 8, 2019,
<https://www.lullabot.com/articles/convincing-docker-and-iptables-play-nicely>.

I see little risk in using known passwords here, but it's such a bad
practice that I'd rather avoid it entirely.

(The worst case I can imagine is that a malicious process running on the
developer's workstation would be able to manipulate the configuration.)

- Vagrantfile: Correct the path to the parsed YAML file. (This caused
  'vagrant global-status' to fail when called from outside the project's
  directory.)

- Vagrantfile: As we do not use it, disable the default sharing of the
  project's directory with the VMs.

- lockss: Use /tmp as temporary directory.

- Other trivialities.