Using the old salt.engines pillar and merging it with the new
salt.[master|minion].engines pillar.
This way, it doesn't break previous behavior and permits to define
common engines on master and minion.
In the merge, the salt.[master|minion].engines pillar takes precedence
if conflict as it's the more specific pillar.

the engines are now configured using the following pillars:

* salt.master.engines
* salt.minion.engines

instead of a global salt.engines pillar.

Note: the pillar.example provided seems to assume this behaviour.
(the pillar is salt.master.engines.slack and not salt.engines.slack)

Signed-off-by: Rene Jochum <rene@jochums.at>

Signed-off-by: Rene Jochum <rene@jochums.at>

This avoids problems when values are strings containing colons. And it
mimicks what was already done for the salt-minion's configuration file.

Fixes #233.

- When it's iterable, the minion could be running on the master
- When it's a string, there's no advantage over just specifying
  `salt:minion:master`

This makes it easier for users to check the status of jobs that ran into
a timeout.

With a simple pillar like this::

    $ sudo salt-call --config-dir /srv/etc/bootstrap --pillar-root /srv/pillar pillar.get salt:pillar_roots
    local:
        ----------
        base:
            - /srv/pillar

This was generated in /etc/salt/master.d/f_defaults.conf::

    # highstate format, and is generally just key/value pairs.
    pillar_roots:base:- /srv/pillar
    #

Resulting in parse errors by salt::

    $ sudo salt '*' state.highstate
    [ERROR   ] Error parsing configuration file: /etc/salt/master.d/f_defaults.conf - while scanning a simple key
      in "<string>", line 531, column 1:
        pillar_roots:base:- /srv/pillar
        ^
    could not found expected ':'
      in "<string>", line 532, column 1:
        #
        ^
    [ERROR   ] Error parsing configuration file: /etc/salt/master.d/f_defaults.conf - while scanning a simple key
      in "<string>", line 531, column 1:
        pillar_roots:base:- /srv/pillar
        ^
    could not found expected ':'
      in "<string>", line 532, column 1:
        #
        ^

This patch will fix it as such::

          ID: salt-master
    Function: file.recurse
        Name: /etc/salt/master.d
      Result: True
     Comment: Recursively updated /etc/salt/master.d
     Started: 11:37:12.946823
    Duration: 6255.296 ms
     Changes:
              ----------
              /etc/salt/master.d/f_defaults.conf:
                  ----------
                  diff:
                      ---
                      +++
                      @@ -528,7 +528,9 @@
                       # Pillar is laid out in the same fashion as the file server, with environments,
                       # a top file and sls files. However, pillar data does not need to be in the
                       # highstate format, and is generally just key/value pairs.
                      -pillar_roots:base:- /srv/pillar
                      +pillar_roots:
                      +  base:
                      +    - /srv/pillar
                       #

Resulting in::

    # highstate format, and is generally just key/value pairs.
    pillar_roots:
      base:
        - /srv/pillar
    #

This commit fixes how `pillar_roots` are generated and after this fix the
generated configuration does not contain any unnecessary new lines:

```yaml
pillar_roots:
  base:
     /srv/salt/dir1
  dev:
     /srv/salt/dir2
     /srv/salt/dir3
  locale:
     /srv/salt/dir4
```

Before this commit the pillar_roots in `f_defaults.conf` for master would be
generated with a lot of empty lines in between directories, like this:

```yaml
pillar_roots:

  base:

     /srv/salt/dir1

  dev:

     /srv/salt/dir2

     /srv/salt/dir3

  local:

     /srv/salt/dir4

```

The minion configuration is not affected and renders fine.

The user will already have it's /etc/salt/minion file, so it doesn't need all this info, and it makes easier to know what has been generated and what not

Needed because salt-cloud will attempt to load them even if they are
filled with invalid default values, creating error spam.