(Maint) Inject Pidlock dep into Daemon

While trying to understand several different code paths in the
Puppet::Daemon code the realization that the tests for the daemon code
had to mock internal methods on the class under test caused me worry. By
removing the mocking of the internal methods it was obvious that there
was another collaborator that is a locking service at play. Services
should normally be injected into, and not created by, the consumer of
the service.

This injects the Puppet::Util::Pidlock into the Daemon and reworks the
points of construction of Daemon objects so that the correct information
is available at the point of construction. This require moving the
Daemon creation from the preinit methods to the setup or run methods in
order to ensure that command line processing and therefore Puppet#[] was
ready at the point of construction so that the correct Puppet[:pidfile]
could be used.
(Maint) Inject scheduler into Daemon

By injecting the scheduler into the Daemon we can provide a different
one during testing that allows us to cleanly check what the jobs are
that the Daemon will be running.
(Maint) Clean up Daemon tests

The Daemon tests were relying on a lot of instance variables and stubing
the class under test. This removes that.
(Maint) Remove unused register code for Server

The Puppet::Network::Server class seems to have atrophied over time.
There are multiple redundant or unused code paths in it.

This commit removes the "registration" facility for the network server
to handle certain indirections. There were no users of these outside of
the tests and there is no functionality that they provided. The only
thing the registration of indirection names did was check to see if such
an indirection existed. I believe that at one point these had been meant
to act as a per-server handling facility (as indicated by one of the
test names), but they no longer serve such a purpose.
(Maint) Remove duplication btwn Daemon and Server

The Puppet::Network::Server had a lot of the same code as the
Puppet::Daemon (closing filehandles, managing a pidfile for locking).
There was a comment in the Server class that indicated that it was not
even clear if the duplicate code was being used.

It turns out that the code was being used, but was incorrect. By turning
on debug and watching the log output of the master, you were able to see
that the close_streams was happening twice, as you would expect by
following the code paths. There is no need for this to happen. In
addition the pidfile is managed twice. This was discovered by
instrumenting the code with a debug statement and noticing that the
pidfile was locked 3 times (one from the server, one from the daemon,
and one more from an unclear location).

Removing all of this turns Puppet::Network::Server into a simple wrapper
around the WeBrick code, reduces the overhead for daemonizing, and
clarifes the pid as lockfile ownership.
(Maint) Mark the Puppet:Daemon private

The Daemon code is an internal implementation of how we create our
master and agent processes. Others should not rely on it. This also
hides some of the internal handling methods (for managing the pidfile).
(Maint) Document Puppet::Daemon

The Daemon code is getting better, but is still not the clearest thing
in the world. This adds some class documentation that tries to clarify
the parts of the daemon.