Fix issue with EOF parsing

Seems like I had a bug with parsing when we didn't have a blank line when we reached EOF.

That didn't seem to be much of a problem when using halfpike to lex/parse something like a router config, where you are sweeping over a lot of details. But when using it to parse an IDL language where every character is important, this was a problem.

So, we'd have something like this:

{
  a: "b"
}```

The last line would emit Item{Type: ItemEOF, Val: "}"}, when it should emit two values, one of ItemText and one of ItemEOF.

Also, I was doing some weird stuff with EOF.  There is no EOF character in UTF-8, we simply know how large the file is.  Because the lexer is run based, I was emitting a character to signal EOF. That character was not good, so I'm using the control character now of '\x01'.  But I was also emitting that character in Raw in some places. I've stopped doing that, as that isn't real.  

Left a debug line in

Puts out a bunch of annoying character.

Bug regression fix

Had a bug where a Line.Raw might start with \n if the line before it was a blank line. Since we don't want that, chopping it off in the lexer before the Item gets sent along for parsing.

Also added a regression test and fixed up another test.

And added stringer go generate for ItemType.

Update some bad README stuff

v0.3.1

update README

Add DecodeList{} type to handle decoding lists of items

You know, those damn pesky lists in a line, like ["something", "probably", "important"].

Well, they are a pain to handle and I wrote a generic way to decode them, as long as they are on a single line.

Merry Christmas to all.

Breaking Changes to make it easier to use, add more docs, etc.

Now with a README

Made Parser() easier to deal with and less circular in dependencies.
New "line" package to help parse lines from .Raw when you need all that whitespace.
....

Initial release

Includes the initial version of the HalfPike lexer/parser and examples.