(PUP-3035) Add /var/run/puppet to debian packaging

Previously /var/run/puppet was created only during service start on
debian for both puppet and puppetmaster services. However, as it is used
in both of those services, it makes sense to have it owned and created
by one of the puppet packages. puppet-common is a dependency of both the
puppet and puppetmaster packages, so this commit adds /var/run/puppet to
the puppet-common.dirs file so it will be created in that package. This
also brings parity between redhat and debian packages in this respect,
as redhat puppet packages create the /var/run/puppet directory already.
This also adds a dpkg-statoverride call to manage permissions for the
/var/run/puppet directory.
(PUP-3035) Refactor dpkg-statoverride calls in puppet-common.postinst

This commit does some simple refactoring int he puppet-common.postinst
to avoid some unneeded repetition.
(PUP-2349) Force mode property to be a string

The initial commit for this ticket missed the case where
the mode value isn't explicitly specified but rather comes from
source permissions of a file resource, e.g. as happens during
pluginsync.

This change ensures that mode from a source permission is
converted to an octal string if it's a Numeric.
(PUP-2349) Specify mode as an octal string consistently in spec manifest snippets

In the puppet 4.0 parser, the file resource's mode property will be
required to be a string containing an octal (or symbolic) representation
of mode.

For consistency then, this commit changes all cases where mode was
specified as a Numeric to be a string containing an octal representation
of mode (always prefaced with a 0, again for clarity and consistency).
Merge pull request #3022 from kylog/issue/pup-2349/cleanup-warning-during-pluginsync

(PUP-2349) cleanup warning during pluginsync.
Merge pull request #3001 from haus/ticket/master/pup-3035-add-var-run-puppet-to-debian-packaging

(PUP-3035) Add /var/run/puppet to debian packaging
(PUP-1884) Migrate MSI deps into puppet repo

We have this problem where it is very difficult to know what exactly is
getting into the Puppet MSI when we build it. Previously, all that
information was stored in the Jenkins job used to build the MSI. This
proved difficult because there is no real way to audit changes made to
Jenkins jobs, why those changes were made, or who made them. This commit
moves that information into the Puppet Repo itself. This will help us
make sure the correct version of each project is getting into the MSI,
and allow us to build the MSI with the current checkout of the Puppet
Repo. However, this means we have to make sure we do not forget to
update the versions of the dependencies getting pulled into the MSI when
a new release happens.