Greatly simplify Salt's setup.py script logic
Force saltenv to be a string when passed to state compiler
Load gitfs config values as strings
Load hgfs config values as strings
Load svnfs config values as strings
Don't try to use text_type to force saltenv to be unicode

This breaks salt code that uses raw string formatting (i.e. {0!r})
Added inspect option to modules.dockerio.get_containers to return more
graunular information about running containers.
Make sure `kwargs=None` is properly handled. Fixes #16945.
Prevent stacktrace if wrong type in outputter with state_verbose False

Closes #16488
Fix file.managed backup feature on Windows
add missing module import
add comment that ':' is illegal on Windows

Windows file paths and names cannot contain a ':'
fix pylint error
Fix syntax error
reliably stop windows services

`net stop` issues a stop command to the target service and waits
briefly (~30s), but will give up if the service takes too long to stop
with a misleading "service could not be stopped" message. `net stop`
will report failure, but some time later the service may actually stop
on it's own.

The common solution for really knowing when a service is stopped is to
poll using `sc query`, which is what this patch does for failed `net
stop` commands.

Adds two configuration constants which might need tweaking:

* `SERVICE_STOP_DELAY_SECONDS` - how many seconds to wait in between poll
  attempts
* `SERVICE_STOP_POLL_MAX_ATTEMPTS` - how many poll attempts to make
  before giving up

Most of the batch-file based solutions posted by windows admins are
unbounded polling, but I'm not comfortable with infinite loops so I
added the max attempts guard.

Right now I have these set to 15s and 5 attempts, so salt will wait 5*15
= 75s for services to stop, which might need some tweaking.

See also:

* http://stackoverflow.com/questions/3325081/how-to-check-if-a-service-is-running-via-batch-file-and-start-it-if-it-is-not-r
* ​http://stackoverflow.com/questions/1405372/stopping-starting-a-remote-windows-service-and-waiting-for-it-to-open-close
`net stop` return code is misleading, check stdout

When `net stop` gives up waiting for a service to stop, it still has
retcode 0, so we need to check the actual output to tell if it worked or
not. If we see "service was stopped" we consider it good, otherwise
start polling.

Sample `cmd.run_all` output for the `net stop` failure case:

    pid:
        6360
    retcode:
        0
    stderr:

    stdout:
        The NSClient++ (Win32) service is stopping........
        The NSClient++ (Win32) service could not be stopped.

Sample `cmd.run` output for the when `net stop` works as intended:

    The NSClient++ (Win32) service is stopping...
    The NSClient++ (Win32) service was stopped successfully.
Refactor salt.utils.filecopy() out of salt.utils

Done to ease the use of salt.modules.selinux here. Added better checking
for selinux to fix #16999
Update to latest stable release of the bootstrap script, v2014.10.30

* Apply the forking patch to openSUSE git installations.
Remove the "unknown" fallback
Merge pull request #17020 from s0undt3ch/hotfix/bootstrap-script

Update to latest stable release of the bootstrap script, v2014.10.30