Remove `CommandManager.GetCommandInfo`.

This broken method does nothing but return `null`. And it's not called anywhere.
Add NYI for `CommandIsScript`.

I don't know when this will happen, but I want to be sure to find out
when it does.
TEST: Allow TestHost to report errors without failing.
Issue #6: Report an error on unrecognized commands.

This bug has been plaguing me for a long time.

A rough sketch of the problem: when we go to execute user input, it might
be an already-known command ("Get-ChildItem") or alias ("gci") or a
pipeline or a script reference. If it's a pipeline, we have to parse it
and analyze/execute each command in the pipeline. If it's a script, we
have to read the file from disk and analyze/execute it. This is a
recursive process.

When I introduced the new Irony parser, I created a bug where the
recursion was infinite if the command wasn't recognized.

I have been struggling to understand the system & how it _should_ work
ever since I introduce the bug 6 months ago. I still don't know the answer
to that question. However, I realized I could inspect the parse tree
before deciding whether to recurse further, and was thus able to eliminate
the bug.

Unfortunately the fix is a bit ugly. My guess is that this logic should
be an `AstVisitor`, perhaps part of `ExecutionVisitor`. Some refactoring
is in order. Still, the bug is so severe that I think it's appropriate to
commit this fix as-is.
REFACTOR: reverse conditional
REFACTOR: Make the search for commands symmetrical.
Merge pull request #19 from JayBazuzi/issue6

Fixes #6: Fix crash on unrecognized command.