do not specify file modes unless relevant

MODULES-10583 makes a good point: "why are you messing with my file
permissions"? In my case, the entire reason I made the following
change (in PR #906):

ab2e06b72f2be8dc38d6e3ecec68dc2cdacbce4e MODULES-10548: make files readonly

... is exactly *because* Puppet was changing the file modes from under
me. I was migrating from our own in-house APT module to the forge one,
and our module did *not* intervene in those file modes: it left the
file resources alone. Which means we could have a directive like this:

File {
    owner   => root,
    group   => root,
    mode    => '444',
    ensure  => file,
}

... which made all files readonly by default. So when I migrated to
the Puppetlabs APT module, modes were changed to be writable, which I
did not want.

As I reasoned in MODULES-10548, having files readonly provides an
excellent indicator that a file is managed by Puppet, even if some
module does not add a warning header - either because it forgot or
because it's impossible. But I also understand if people do not like
that policy.

I think the proper way of doing this is not specifying a mode at all,
and let local site-specific policies apply. I specifically proppose
this as an alternative to #921 because I believe adding more
parameters to the resources will needlessly complicate the script,
when we have a native, Puppet-DSL supported way of changing those
modes according to the right scope and context.

In a similar way, we might want to reconsider user and group ownership
of the files, but that can be done in a later time.

This reverts commit 316fd8f4dd1eb6595b3be495ccc5f4924da4de1b.

Signed-off-by: Antoine Beaupré <anarcat@debian.org>