Perform major API changes

This set of patches includes multiple changes and is not backward-compatible.

In summary this code:
- Supercedes PR 99 (MODULES-1075), 97, 96, 94, 93, 85, 82, 80, 79, 51, 69, 66
- Explicitly makes Debian 6 unsupported
- Makes nodejs, nodejs-dev and nodejs-debug package names parameters
- Defaults to using the NodeSource repositories where possible, but allows
  native packages to be installed when appropriate parameters are set
- Introduces a parameter repo_class, which allows one to use alternative
  repositories like EPEL for the Node.js packages.
- Adds Windows installation support via Chocolatey
- Adds a defined type nodejs::npm::global_config_entry, which allows one to
  set and delete global NPM config options. The proxy parameter has been
  removed since this can be done with nodejs::npm::global_config_entry
  instead.
- Attempts to support bleeding edge operating systems with likely defaults
  rather than failing hard.
- Includes detailed RSpec unit tests
- Adds Beaker acceptance tests

1. It might be possible to modify this code to be backward-compatible with
the current version, but it seems like a lot of work. If one follows the
SemVer guidelines, breaking the API for 0.x releases is perfectly okay.

2. While this code forces the global config settings proxy and https-proxy
to be applied first before any local NPM packages are installed, it
does not do something similar with the (global) NPM provider type.
I'm not sure if there is a way to achieve something similar.

3. This code adds an explicit dependency on the gpg_key module for
importing the YUM repository keys. I'm not sure if this is a something that
is preferred for PuppetLabs modules in particular.

4. There is a need for the npm_path parameter since Windows, Darwin and
possibly others default to installing NPM in various places. The npm
defined types have been modified to accommodate this, but the provider has
not.

5. Looking at the commit history and various uses of Node.js, it seems clear
that the package is frequently installed on 'bleeding edge' operating systems,
if only for development use. Hence, it does not always make sense to explicitly
support certain operating systems only and fail hard on anything else. Are there
any major objections to doing things this way?

6. A lot of the RSpec unit tests are in the same file. Are there any major objections to this?