Fix broken tests when supplying test flags

Passing test flags to `go test` (e.g. `go test -test.v`) is breaking the default handler assertions in TestGo and TestCommander_execute:
```
=== RUN TestArgument_MakeArgument
--- PASS: TestArgument_MakeArgument (0.00 seconds)
=== RUN TestArgument_Represents
--- PASS: TestArgument_Represents (0.00 seconds)
=== RUN TestArgument_ParseArgument
--- PASS: TestArgument_ParseArgument (0.00 seconds)
=== RUN TestArgument_isLiteral
--- PASS: TestArgument_isLiteral (0.00 seconds)
=== RUN TestArgument_isList
--- PASS: TestArgument_isList (0.00 seconds)
=== RUN TestArgument_isCapture
--- PASS: TestArgument_isCapture (0.00 seconds)
=== RUN TestArgument_isOptional
--- PASS: TestArgument_isOptional (0.00 seconds)
=== RUN TestArgument_isVariable
--- PASS: TestArgument_isVariable (0.00 seconds)
=== RUN TestArgument_isEqualTo
--- PASS: TestArgument_isEqualTo (0.00 seconds)
=== RUN TestCommand_makeCommand
--- PASS: TestCommand_makeCommand (0.00 seconds)
=== RUN TestCommand_Represents
--- PASS: TestCommand_Represents (0.00 seconds)
=== RUN TestCommand_IsEqualTo
--- PASS: TestCommand_IsEqualTo (0.00 seconds)
=== RUN TestCommander_Map
--- PASS: TestCommander_Map (0.00 seconds)
=== RUN TestCommander_execute

usage: commander <command> [arguments]


--- FAIL: TestCommander_execute (0.00 seconds)
        Location:       commander_test.go:46
	Error:		Should be true
		
=== RUN TestCommander_NoOptional
--- PASS: TestCommander_NoOptional (0.00 seconds)
=== RUN TestCommander_Real
--- PASS: TestCommander_Real (0.00 seconds)
=== RUN TestGo

usage: commander <command> [arguments]


--- FAIL: TestGo (0.00 seconds)
        Location:       go_test.go:20
	Error:		Should be true
		
FAIL
exit status 1
FAIL	github.com/stretchrcom/commander	0.023s
```
Turned out that `go test`'s flags were showing up in `os.Args` and interfering with the tests. Hardly a big deal, but in case you're interested I've attached a fix that changes `execute` to distinguish between `incomingArgs` being unset (as it would be in real usage) vs. when it is set but empty (as it is by the test cases). What do you think?

Cheers for the helpful library by the way!