Always wrap salt-call return dict

Please carefully review this before merging. It looks like it is the right thing to do, and I tested each of the following to make sure there was no unintended breakage:

1. Using salt-call.
2. Calling functions from the master the "normal" way.
3. Calling functions using peer publishing.

Everything works as expected, so I think this should be a good change. It also makes output more consistent, since running ``salt-call network.ip_addrs eth0`` would return output with a top-level ``local`` key, while running ``salt-call network.interfaces``, ``salt-call pillar.items``, ``salt-call grains.items`` or anything else that returns a dict, would have output that lacked this top-level ``local`` key.

So yeah. Looks good to me, but I'd certainly welcome extra eyes on this. Commit message follows:


salt.cli.caller.Caller.run() was checking if the return data was a dict,
and wrapping it in an outer dict like so: {'local': ret['return']} if
the data was not a dict, to ensure that the return data is in the right
format for the different outputters.

The problem with this is that there are many execution functions that
already return a dict, such as network.interfaces, grains.items,
pillar.items, etc. These will not be wrapped. This results in a
traceback when running grains.items via salt-call, since the grains
outputter expects the return data to be a dict of dicts, with the
top-level keys being the minion id and the 2nd level being the minion's
grains dict.

This commit removes the isinstance check and simply always wraps the
return data in the 'local' dict.