FEATURE REQUST: add "--sudo" option to "vagrant ssh/push/pull" et al.

[ladar]

I routinely use scripts to interact with my Vagrant boxes, and many of those script run commands using the standard vagrant ssh -c "command" paradigm.

While I can use arcane shell tricks to inline sudo with commands, it ould be nice if I didn't have to. One major issue is error handling, as its difficult to differentiate an issue where sudo access isn't granted for some reason, and a problem with the command itself.

Placing the logic in a shell script, which is pushed to the box, then executed via the vagrant ssh -c paradigm does provide a solution in some contexts, but doesn't work well with "one liners."

In isolation, this feature is only of moderate importance, but if you consider the implications of adding this option to the vagrant push command, and the vagrant pull feature I outlined in #12735 it would provide a lot more value, as it would make pushing files to, and pulling files from, exponentially easier when the default vagrant user doesn't have access. Consider the logic needed to download a system log files from a box - such as when an automated CI process/build fails - when the vagrant user doesn't have access:

  vagrant ssh-config > ssh_config
  vagrant ssh -c 'sudo cp /var/log/messages /home/vagrant/messages.txt' 
  vagrant ssh -c 'sudo chown vagrant:vagrant /home/vagrant/messages.txt'
  printf "get messages.txt\nquit\n" | sftp -F ssh_config default
```bash
A far more elegant approach would be:

vagrant pull --sudo /var/log/messages messages.txt

The current approach, using ssh + sftp, , requires lots of guest specific workarounds, depending on the target OS 

Each target OS uses different locations, filenames, and/or access restrictions to extract OS logs. Some also require running a command with elevated access to save the relevant data out to a file. Consider the growing number of systems which require elevated permissions to use `dmesg` or `journalctl`, and the many situations where preserving, and then extracting that info, and saving it as part of a job log, might be neccssary to identify, and rectifya problem that occurs inside a Vagrant box used as part of a CI pipeline.







And with the current crude approach, it's difficult/impossible to use a generic set of commands for every guest operating system/situation because the layers make modifying command flow based using errors difficult.