This covers:

* The lexing.
* The reason for why we can't just evaluate the series of tokens
  from the lexer directly.

TODO:

* Parse the damn tokens into statements, and then execute them.

This commit removes our implementation; at this point we have
a lexer that appears to work - at least the test-cases pass - but
nothing using it.

TODO:

* Add a some sub-command stub to test the lexer.

Updated `HACKING.md` to describe how I'm going to parse; specifically
that we'll recycle the token-types in `token/token.go`.

Should be easy, but first tea :)

I've added the sub-command framework I'm most familiar with, and
now I can successfully lex our example recipe:

    frodo ~/go/src/github.com/skx/deployr $ ./deployr lex ./example.recipe
    {Set Set}
    {IDENT greeting}
    {STRING Hello, world!}
    {CopyTemplate CopyTemplate}
    {IDENT example.recipe.template}
    {IDENT /tmp/blah}
    {Run Run}
    {STRING cat /tmp/blah}
    {IfChanged IfChanged}
    {STRING sha1sum /tmp/blah}
    {EOF }

TODO:

* Write the parser.
* Test the parser.
* Use the parser.

Random-testing of our lexer to dump broken-programs revealed
the fact that we silently closed open-strings at EOF.  This is
friendly and helpful, but wrong.

Correctly return an error for this input:

        Run "test

Error is "Unterminated string!" which is nice and descriptive.

The parser is driven by the new `parse` sub-command, which shows
parsing good/bad programs like so:

    frodo ~/go/src/github.com/skx/deployr $ ./deployr parse ./example.recipe
    {{Set Set} [{IDENT greeting} {STRING Hello, world!}]}
    {{CopyTemplate CopyTemplate} [{IDENT example.recipe.template} {IDENT /tmp/blah}]}
    {{Run Run} [{STRING cat /tmp/blah}]}
    {{IfChanged IfChanged} [{STRING sha1sum /tmp/blah}]}

    frodo ~/go/src/github.com/skx/deployr $ ./deployr parse ./t.in
    Error parsing program: Error retrieceved from the lexer - Unterminated string!

As expected the parsed-results are just an array of "Statements" where
statements hold a single token as the thing to invoke, and an array
of (up to) two potential arguments.

This catches the case of:

        echo '"Test"' > t.in
        ./deployr parse t.in

We can now run our example!  First run shows both commands
work, as expected:

    frodo ~/go/src/github.com/skx/deployr $ ./deployr run --target=master.steve.org.uk:2222 ./example.recipe
    This file was deployed to master.steve.org.uk by deployr!

    Here you see a variable being used which was defined in the recipe itself:

    * Hello, world!
    5649664271eb6d14e7073ca98cf1dffa4ec1e5d0  /tmp/blah

Second run results in no change, so the "IfChanged" execution
doens't run:

    frodo ~/go/src/github.com/skx/deployr $ ./deployr run --target=master.steve.org.uk:2222 ./example.recipe
    This file was deployed to master.steve.org.uk by deployr!

    Here you see a variable being used which was defined in the recipe itself:

    * Hello, world!

Expand "${foo}" to the content of the variable "foo", in all
our functions.

This should be "Run foo .. bar":

        Run "foo \
   bar";

If you want a newline you should add one.  This might surprise
coders, but if we pretend we're bash-scripts it makes more sense.

Also moved variable-discussion into its own section.

Now we can add a test for it.

This is a good thing :)

This will allow us to mock our lexer for tests.