(PUP-2871) Add :install_options and :uninstall_options to the pacman provider

Without this patch, a user unfamiliar with the pacman provider might write
attempt to add flags to install and uninstall, not knowing that they will fail.
This patch adds support for these two flags to ensure a more cohesive experience
across puppet.
(PUP-2948) enable rubocop for travisCI

Previously, the Rubocop gem was added to development and testing groups without
any further constraints. However, this caused failures in windows platform, due
to its dependency on json. Since we are using only multi-json, we do not want
to have this dependency added. So this commit restricts rubocop to
non-windows native rubies.
Merge pull request #2916 from vrthra/rubocop/puppet-4/gem-fix

(PUP-2948) enable rubocop for travisCI
(maint) use RSpec helpers over instance and local variables
(maint) Isolate specs from whether yaourt is installed
(PUP-2871) Concatenate install install_options to argv

Before this commit, install_options were passed as a nested array to
pacman/yaourt. This commit changes that to concatentate the values
with the argument vector.
(PUP-2871) Concatenate uninstall_options to argv

In the same manner as 9137faf uninstall_options were being appended as a
nested array value; this commit changes the uninstall method to
concatentate options to the array.
(maint) Make pacman (un)install_options private

These methods should not be called by any outside class; this commit
makes them private and removes the tests that invoke them directly.
(PUP-2388) Puppet acceptance for Ruby 2 x64

 - Select puppet-win32-ruby branch based on the :ruby_arch host variable
 - Apply permissions a little differently based on how file paths are
   setup in the newer Ruby 2 builds
 - Note that at this time, the puppet-win32-ruby build for x64 does not
   work on Windows 2003 x64 due to 2 missing functions in MSVCRT on that
   platform
 - YAML job definitions are updated in subsequent commit
(PUP-2388) Update Windows Jenkins matrix defs

 - Ensure that there are single YAML files per job type, which allows
   for a more granular selection of node definitions through Jenkins.
   NOTE: by using job definitions that are laid out horizontally
   (by file), rather than adding multiple node definitions to a single
   YAML file, this allows for better parallel execution of the suite.
   Agent requests are presently serialized within Beaker when all agent
   definitions occur within a single YAML configuration.
 - In that vein, trash these (though Git may show some as renamed):
    win2003-all.yaml
    win2008-all.yaml
    win2012-all.yaml
    windows-all.yaml
 - Spec out all valid combinations of 2003, 2003R2, 2008, 2008R2, 2012
   and 2012R2 with Ruby x86 and Ruby x64 where applicable, depending
   on what the platform supports.
 - Not all of these configurations will be used, but keep all of the
   definitions for the sake of local testing / maintaining a valid list
   of operating systems where Puppet could be run on Windows.
 - Note that FILECOUNT was also removed as a Beaker option where it was
   defined, since it is a deprecated option.
 - Note that at this time, the puppet-win32-ruby build for x64 does not
   work on Windows 2003 x64 due to 2 missing functions in MSVCRT on that
   platform
Merge pull request #2918 from adrienthebo/fixup/master/pup-2871-install-uninstall-options-pacman

Fixup/master/pup 2871 install uninstall options pacman
Merge pull request #2903 from Iristyle/ticket/master/PUP-2388-Puppet-acceptance-Ruby-2

(PUP-2388) Puppet acceptance for Ruby 2 x64
Merge branch 'master' into puppet-4

* master:
  (PUP-2388) Update Windows Jenkins matrix defs
  (PUP-2388) Puppet acceptance for Ruby 2 x64
  (maint) Make pacman (un)install_options private
  (PUP-2871) Concatenate uninstall_options to argv
  (PUP-2871) Concatenate install install_options to argv
  (maint) Isolate specs from whether yaourt is installed
  (maint) use RSpec helpers over instance and local variables
  (PUP-2871) Add :install_options and :uninstall_options to the pacman provider
(PUP-2950) ensure that default layer is used when the user has not provided a layer

Without this patch,

```
      unless diagnostics.errors?
        @layering_config   = data['layers'] or default_layers
        @scheme_extensions = (data['extensions'] and
                  data['extensions']['scheme_handlers'] or
                  default_scheme_extensions)
      else
        @layering_config = []
        @scheme_extensions = {}
      end
```
This would have resulted in @layering_config not being assigned a value if no
layers was set. This is clearly not intented. This patch updates the behavior
so that `@layering_config` is assigned default_layers instead
(by changing `or` to `||`)

This commit also adds test cases to verify that this case is caught.
(PUP-2950) enabling rubocop Style/AndOr cop in pops directory

This commits enables `AndOr` cop only in lib/puppet/pops directory. This cop
bans the use of `and` and `or` keywords in favor of `&&` and `||`. We have
chosen this directory as a test case to evaluate the utility of enabling
`AndOr` on the complete codebase. We inherit from the base rubocop file, so all
the other cops remain enabled. At a future date, when `AndOr` is enabled
systemwide, this file may be removed (if no other specialization exists on pops
directory).

It changes all code that uses `and` and `or` keywords to use `&&` and
`||`  instead. Note that this commit only fixes the lib/puppet/pops directory.
Further, for ease of verification of correctness, redundant parenthesis has
been used around the expressions thus converted where there was felt to be
a possibility of confusion.
(PUP-2950) Enable rubocop Style/AndOr in lib/ (enable)

This is part of a series of commits that follows the same pattern. These
checkins remove use of `and` and `or` keywords, and enable the Style/AndOr cop
so that future use of `and` and `or` is banned (and instead `&&` and `||` is
encouraged)

For the ease of modification, and to ensure that the possible errors remain a
minimum, we have attempted to make the changes as consistent to each other as
possible, and have also given preference to explicit parenthesis where doing so
helped.

Our approach has been to
- Let rubocopop autocorrect where possible
- Look for regular expression patterns that could catch the maximum number of
  violations without ambiguity, and apply these to the code, and then manually
  verify that the changes have indeed been correct (and correct where
  necessary).
- Once such patterns were exhausted, the remaining changes were done by hand.

This commit enables the `AndOr` cop
(PUP-2950) Enable rubocop Style/AndOr in lib/ (autocorrect)

This is part of a series of commits that follows the same pattern. These
checkins remove use of `and` and `or` keywords, and enable the Style/AndOr cop
so that future use of `and` and `or` is banned (and instead `&&` and `||` is
encouraged)

For the ease of modification, and to ensure that the possible errors remain a
minimum, we have attempted to make the changes as consistent to each other as
possible, and have also given preference to explicit parenthesis where doing so
helped.

Our approach has been to
- Let rubocopop autocorrect where possible
- Look for regular expression patterns that could catch the maximum number of
  violations without ambiguity, and apply these to the code, and then manually
  verify that the changes have indeed been correct (and correct where
  necessary).
- Once such patterns were exhausted, the remaining changes were done by hand.

Rubocop: autocorrect
(PUP-2950) Enable rubocop Style/AndOr in lib/ (fix spacing)

This is part of a series of commits that follows the same pattern. These
checkins remove use of `and` and `or` keywords, and enable the Style/AndOr cop
so that future use of `and` and `or` is banned (and instead `&&` and `||` is
encouraged)

For the ease of modification, and to ensure that the possible errors remain a
minimum, we have attempted to make the changes as consistent to each other as
possible, and have also given preference to explicit parenthesis where doing so
helped.

Our approach has been to
- Let rubocopop autocorrect where possible
- Look for regular expression patterns that could catch the maximum number of
  violations without ambiguity, and apply these to the code, and then manually
  verify that the changes have indeed been correct (and correct where
  necessary).
- Once such patterns were exhausted, the remaining changes were done by hand.

REGEX USED:
(PUP-2950) Enable rubocop Style/AndOr in lib/

This is part of a series of commits that follows the same pattern. These
checkins remove use of `and` and `or` keywords, and enable the Style/AndOr cop
so that future use of `and` and `or` is banned (and instead `&&` and `||` is
encouraged)

For the ease of modification, and to ensure that the possible errors remain a
minimum, we have attempted to make the changes as consistent to each other as
possible, and have also given preference to explicit parenthesis where doing so
helped.

Our approach has been to
- Let rubocopop autocorrect where possible
- Look for regular expression patterns that could catch the maximum number of
  violations without ambiguity, and apply these to the code, and then manually
  verify that the changes have indeed been correct (and correct where
  necessary).
- Once such patterns were exhausted, the remaining changes were done by hand.

REGEX USED:
    Replacing only the simplest pattern

    s#^( *)if +([^ ]+) +and +([^ ]+)$#$1if $2 && $3#g
    s#^( *)if +([^ ]+) +or +([^ ]+)$#$1if $2 || $3#g
(PUP-2950) Enable rubocop Style/AndOr in lib/

This is part of a series of commits that follows the same pattern. These
checkins remove use of `and` and `or` keywords, and enable the Style/AndOr cop
so that future use of `and` and `or` is banned (and instead `&&` and `||` is
encouraged)

For the ease of modification, and to ensure that the possible errors remain a
minimum, we have attempted to make the changes as consistent to each other as
possible, and have also given preference to explicit parenthesis where doing so
helped.

Our approach has been to
- Let rubocopop autocorrect where possible
- Look for regular expression patterns that could catch the maximum number of
  violations without ambiguity, and apply these to the code, and then manually
  verify that the changes have indeed been correct (and correct where
  necessary).
- Once such patterns were exhausted, the remaining changes were done by hand.

REGEX USED:

Replacing only the simplest patterns

's#^(.*) if +([^ ]+) +or +([^ ]+)$#$1 if $2 || $3#g'
's#^(.*) if +([^ ]+) +and +([^ ]+)$#$1 if $2 && $3#g'