Rasbian reports back the following grain values:

local:
    ----------
    os:
        Raspbian
    os_family:
        Debian
    osarch:
        armhf
    osmajorrelease:
        8
    osrelease:
        8.0

Ubuntu reports back the following grain values:

local:
    ----------
    os:
        Ubuntu
    os_family:
        Debian
    osarch:
        amd64
    osmajorrelease:
        14
    osrelease:
        14.04

For Raspbian the osarch needed to be changed from other Debain os_family
distributions.
For Ubuntu the osrelease value is needed instead of osmajorrelease as other
Debian os_family distributions.

Part of #180

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

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

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

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

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

repo.saltstack.com handles all currently supported Debian releases as well
as all supported Ubuntu releases so this change should be fine.

Part of #180.

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.

Without this change, importing map.jinja in config files (as opposed to
SLS files) causes a rendering error because `slspath` isn't defined.
The `salt_settings.key_url` variable gets used only in
`salt/pkgrepo/debian/init.sls`.

This adds some minimal support for Windows minions.

This restores the original structure/behavior of the
`salt_formulas` Pillar key.

issue #180

- 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.

Jinja macros are not actually functions.  The only thing they can return
is a string.  In order to return structured data, the callee must
serialize it, and the caller must deserialize it.  This state formula
uses YAML as the intermediary, hence the occurrence of both the
`|yaml` (callee) and `|load_yaml` (caller) filters in its code.

The post-render "mapping values are not allowed here" error in
*salt/formulas.sls* or the broken rendering of
*salt/files/master.d/f_defaults.conf* happens because invocations of the
`formulas_git_opt` macro in several Jinja `set` statements do not get
deserialized, resulting in the trailing newline followed by three dot
characters (`...`), which YAML uses to signal the end of a document.
Correcting these rendering errors requires adding the necessary
deserialization code at those locations (i.e., filtering the macro call
through `|load_yaml`).