(SERVER-85) Sync CA CRL to Host CRL at startup

This commit changes the master to, at each startup, copy the file
pointed at by the Puppet `cacrl` setting, if it exists, over to the
file pointed at by the Puppet `hostcrl` setting.

This commit also changes the `override-webserver-setting!` logic to
use the file at the `hostcrl` setting rather than the one at the `cacrl`
setting to determine which file the webserver uses to validate
certificates for connecting clients.  This was done based on the fact
that a "standalone" master -- one hosted without a corresponding active
CA in the same container -- would have used the `hostcrl` setting under
the Ruby master.  With the logic in place to copy the `cacrl` to the
`hostcrl` when a real CA is in place, the latest CRL, when the master
and CA are running in the same container, should now be in place at
service startup.
Ultimately, I think it would be better if `hostcrl` and `cacrl` were just one setting pointing at the same file.  There really doesn't seem to be any value in the separation.  We're just dealing with that for now because these distinct settings were defined in legacy Puppet.

The scenario I'd typically expect to happen on a monolithic master+CA install is this:

1) User performs administrative action to update the CRL file, e.g., issues revoke via the `certificate_status` endpoint.  This currently updates the `cacrl` file but not the `hostcrl` file.  The `cacrl` file represents the CA service's view of the file whereas the `hostcrl` file is more representative of the master service's view of the file.

2) Sometime later, Puppet Server is restarted so that the CRL file can be reloaded into the web server.

3) During the restart, new `cacrl` replaces stale `hostcrl` content.

4) Web server loads `hostcrl` content and starts using it from that point on to authenticate clients.

I'm not sure how valuable backing up the possibly stale `hostcrl` at bootup is at this point.  This would seem analogous to backing up the old `cacrl` file every time a change is made to it, which we aren't doing either.  (Ultimately, I could see some value in having the ability to restore the CRL as it was at some point in history, e.g., if the user inadvertently revoked a number of certs and wanted to revert back to a snapshot state.  A richer audit trail of revocation actions, replacing the inventory file, would seem to be a better fit for this use case, though).

Probably worth noting that the replacement of `hostcrl` with `cacrl` is basically following the pattern we had established with `localcacert` being replaced by `cacert`, although the likelihood that the CRL is different is much higher in that revocation actions would update the content of the file whereas the CA cert would typically be static.

I'd definitely like to get @cprice404's take on the assumptions this PR makes overall about the role of the `hostcrl`, though, as this has been a bit contentious up to now.