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.
log when we stop waiting for a service to stop

Leave some evidence of the failure for the ops folks.
account for stop failures when restarting services

During restarts, only try to start the service if it successfully
stopped
Fix #16085 pam auth module was not closeing PamHandle. moreinfo: http://pubs.opengroup.org/onlinepubs/8329799/pam_end.htm
pep8
only sleep after `sc` reports we're still waiting

In testing, sometimes `net stop` might not stop the service, but
checking the service using `sc query` immediately afterwards reported
the service as stopped (I suspect a process scheduling issue, but have
no real evidence of that).

Changes the logic to check using `sc query` and then sleep only if we're
not stopped (as opposed to sleep, then check using `sc query`).

This results in a few different execution paths:

* `net stop` works, we exit
* `net stop` fails, `sc query` reports the service is stopped, we exit
* `net stop` fails, `sc query` reports the service is NOT stopped, we
  sleep then check again

This approach should have us sleeping only if we really need to.
Fix for an issue where re-started sub-processes would inherit the signal handlers from the process manager. Then you would end up with stack traces like:

```
Process Publisher-6:
Traceback (most recent call last):
  File "/usr/lib64/python2.6/multiprocessing/process.py", line 232, in _bootstrap
    self.run()
  File "/home/thjackso/src/salt-github/salt/master.py", line 403, in run
    package = pull_sock.recv()
  File "socket.pyx", line 628, in zmq.backend.cython.socket.Socket.recv (zmq/backend/cython/socket.c:5616)
  File "socket.pyx", line 662, in zmq.backend.cython.socket.Socket.recv (zmq/backend/cython/socket.c:5436)
  File "socket.pyx", line 139, in zmq.backend.cython.socket._recv_copy (zmq/backend/cython/socket.c:1771)
  File "checkrc.pxd", line 11, in zmq.backend.cython.checkrc._check_rc (zmq/backend/cython/socket.c:5863)
  File "/home/thjackso/src/salt-github/salt/utils/process.py", line 242, in kill_children
    p_map['Process'].join(0)
  File "/usr/lib64/python2.6/multiprocessing/process.py", line 117, in join
    assert self._parent_pid == os.getpid(), 'can only join a child process'
AssertionError: can only join a child process
```
Use Ubuntu 14 image for ec2 cloud tests instead of RHEL 6
Pylint cleanup
Don't use HVM image type.
Dicts are already iterators over their keys
Don't need keys() dicts are iterators of their keys
No reason to create a copy of the dict in memory, we can just get the key from the key iterator
No need to create a copy of the keys
More keys() removal
more dict cleanup
More dict cleanup
Remove redundant keys() since dict is an iterator of keys
more cleanup
no need to caste keys() to a list since it returns a list