Reading crontab of non-root unix user should read as that user

Crontab on Solaris and Illumos systems with auditing enabled tries to audit attempts by root to read non-root user crontabs. If chef-client runs without an auditing context (as happens by default when running in SMF), these crontab calls will fails with exit status 1.

By switching to the non-root user first (which somehow does not require auditing), we should be able to read user crontabs without an auditing context.

Note that I'm doing some jank at the end to ensure the existing crontab has a trailing newline. I'm open to suggestions if there's a less janky and preferred alternative.
Here's an example in a pry session:

```
[1] pry(main)> require 'mixlib/shellout'
=> true
[2] pry(main)> s = Mixlib::ShellOut.new("false")
=> <Mixlib::ShellOut#70178508613900: command: 'false' process_status: nil stdout: '' stderr: '' child_pid: nil environment: {} timeout: 600 user:  group:  working_dir:  >
[3] pry(main)> s.run_command
=> <Mixlib::ShellOut#70178508613900: command: 'false' process_status: #<Process::Status: pid 15283 exit 1> stdout: '' stderr: '' child_pid: 15283 environment: {} timeout: 600 user:  group:  working_dir:  >
[4] pry(main)> s.format_for_exception
=> "---- Begin output of false ----\nSTDOUT: \nSTDERR: \n---- End output of false ----\nRan false returned 1"
[5] pry(main)> puts s.format_for_exception
---- Begin output of false ----
STDOUT: 
STDERR: 
---- End output of false ----
Ran false returned 1
=> nil
[6] pry(main)> s.error!
Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of false ----
STDOUT: 
STDERR: 
---- End output of false ----
Ran false returned 1
from /Users/ddeleo/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/mixlib-shellout-2.0.0.rc.0/lib/mixlib/shellout.rb:267:in `invalid!'
```

Generally you don't see `format_for_exception` called because `Mixlib::ShellOut` uses it internally to create the error message when you call `error!` (as shown in the example). In this case, I don't recommend it because we'd change the exception class, which would be a breaking change.