Apt update tooling

This gives you the ability to have puppet run apt-get update a few different ways:

  * always
  * daily
  * weekly
  * reluctantly **default**

it determines when to trigger the apt-get exec via a combination of an addition of a script in apt.conf.d that touches a file when apt-get update runs, and a  custom fact which checks the mtime of that file.

all behavior should be covered by spec tests.

additionally fixed up the spec tests to function when running natively on non-debian systems

Please let me know if there are any changes you'd like to see here in order to merge this
It's not just a smell issue, it can cause errors at runtime. It's a bit of a Puppet internal thing. The problem is the following. If you have multiple declarations of the same class in this order:

```puppet
class  { 'apt": params }
include ::apt
include ::apt
```
This will work.

However, if the evaluation order changes and we end up with:

```puppet
include ::apt
class { 'apt': params }
include ::apt
```
This breaks. You can't re-include a class once you've initialised it with the class parameter syntax. So just including `apt` everywhere can cause trouble.

This almost never happens in real life because everyone is a good citizen and just includes the top class in their catalog.

MY preferred way is to access variables from other classes using a 'normal' lookup, so `$::apt::var`. In Puppet 2/3 this has the unfortunate side-effect of the variable becoming `undef` if you forgot to include the top class so it might break in weird-ish ways, but it'll break. In Puppet 4 you'll simply get an error stating that `$::apt::var` is not defined (turn strict variable checking on in Puppet 3 and you get the same).