Use the existing pubkey for the sign in payload

Rather than making a temp file to save out the public key just to read
it back in to give to the master for sign in, we can just read the
existing public key file that was just created.
include msgpack in thin.tgz

While msgpack is an extmod (it uses an platform-dependent .so) it
includes a pure python fallback.  Including it in thin will not create
a protability problem.
Preserve stdout, stderr and retcode from salt-ssh raw command

salt-ssh raw mode only emits stdout lines; it emits neither stderr nor
the return code.  salt-ssh raw works more like cmd.run rather than
cmd.run_all.  Preserving stdout, stderr and the return code are
imperative for validating the results of a salt-ssh raw command.

This stores 'stdout', 'stderr' and 'retcode' in the ret dictionary so
that the complete information can be emitted by the outputter.

Fixes #10432
Appease the pylint gods.

Fixes #10432
Changed pendflag and succedent flag to segment flag and pending ack flag so semantics changed
Group SSH auth options together; make consistent in formatting
add some version infos for cron
Rewrite environ modules
Add more caution to the clear_all option docs
Fix typo in environ module documentation
Updated suse rpm specfiles for 2014-1 release

removed symlinks to systemd service files now pypi tarball
includes pkg folder. Updated spec file to match these sources.
Minor string formatting in environ module
Remove commented code in environ module
Even more mac_user tests!
Ability to destroy instances matching a profile

There exists times when there may be multiple providers for a single
region. For example in ec2 you might have a provider for each region.
When salt-cloud runs get_running_by_names it will return runnung
instances for each provider. The ec2 provider returns all running
instances for the entire region, thus the same instance will return
for each avaliability zone. Once salt-cloud destroys this instance
it will thrown an exception when it tries again.

The logic is, if you can specify a profile when creating, why not
when destroying?

Example:

```bash
root@localhost:~# salt-cloud example1234 -d
[INFO    ] salt-cloud starting
The following virtual machines are set to be destroyed:
  us-west-2b-devops:
    ec2:
      example1234
  us-west-2b-dev:
    ec2:
      example1234
  us-west-2a-dev:
    ec2:
      example1234
  us-west-2a-devops:
    ec2:
      example1234
```

After this fix:

```bash
root@localhost:~# salt-cloud -p usw2a-dev-web example1234 -d
[INFO    ] salt-cloud starting
The following virtual machines are set to be destroyed:
  us-west-2a-dev:
    ec2:
      example1234
```
[salt] begin nova states

Starting with volumes existing, because that is the only one I care
about right this second.
Fix pylint error No space allowed around keyword

```shell
00:09:50 + pylint --rcfile=/var/lib/jenkins/workspace/salt-pr-lint/.testing.pylintrc salt/
00:13:45 ************* Module salt.cloud.cli
00:13:45 salt/cloud/cli.py:241: [E8251(unexpected-spaces-around-keyword-/-parameter-equals), ] PEP8 E251: unexpected spaces around keyword / parameter equals
00:13:45 salt/cloud/cli.py:241: [E8251(unexpected-spaces-around-keyword-/-parameter-equals), ] PEP8 E251: unexpected spaces around keyword / parameter equals
00:13:45 salt/cloud/cli.py:241: [C0326(bad-whitespace), ] No space allowed around keyword argument assignment
00:13:45                     profile = self.options.profile
```
Some refactoring of segmentation
Change the StateFactory naming to follow conventional CamelCase

Previously states like "postgres_user" ended up being named
Postgres_user, which isn't very Pythonic. Now it becomes PostgresUser,
which is much nicer.
Merge pull request #10662 from gtmanfred/nova

[salt] begin nova states