This functionality is factored out of the gido website
so that it can be reused across a wider set of projects.

Follows https://dmitri.shuralyov.com/website/gido$commit/9ec8098d1ae7dcc4e4bcc249640bb5dec2a42b2c.

Enough time has passed since the API was created, and so far, I have
not had desires to change it, nor has anyone else suggested any API
improvements. It's likely going to stay as is, so remove the comment.
If there are good change ideas in the future, it can still be
considered. But the comment was meant for the very early days of the
package's existence, and has outlived its usefulness.

On Windows, a file that hasn't been gofmt'ed can have \r\n line endings.
Though rare and unusual, it's still a valid .go file and needs to be
supported.

The performance cost is not significant compared to the entire task.

	name         old time/op  new time/op  delta
	ParseFile-8  32.4µs ± 1%  32.4µs ± 1%   ~     (p=1.000 n=10+10)

Fixes https://github.com/shurcooL/go/issues/30.

This makes it possible to use this package in contexts where the .go
file is in memory or otherwise not available on disk.

For now, keep ParseFile around as a trivial helper. If it ends up being
not used in the wild much, perhaps it could be deprecated/removed later.

Fixes https://github.com/shurcooL/go/issues/31.

The specification proposal at golang.org/issue/13560 has changed.
This updates the parser implementation for the latest spec
as described at https://golang.org/s/generatedcode:

	Generated files are marked by a line of text that matches
	the regular expression, in Go syntax:

		^// Code generated .* DO NOT EDIT\.$

	The .* means the tool can put whatever folderol it wants in there,
	but the comment must be a single line and must start with Code generated
	and end with DO NOT EDIT., with a period.

	The text may appear anywhere in the file.

The new implementation for this spec is simpler. It uses bufio.Reader
and ReadBytes. The performance can be optimized further by using lower
level IO primitives and allocating less, but the first priority is
getting a correct parser out for the latest spec. It can be optimized
later as needed.

The main cause of inefficiency is having to read the entire file,
without being able to stop early, because the new specification
allows the comment to appear anywhere in the file.

GitHub-Pull-Request: https://github.com/shurcooL/go/pull/29

This new package contains an initial attempt at implementing a parser
for the currently proposed specification for generated disclaimer
comment in golang.org/issue/13560.