Add test coverage for one more edge case, however unlikely it is.

Use t.Fatal instead of t.Error + return, it's shorter and simpler.

Use ReadFile from package os instead of the deprecated io/ioutil.

With the new specification, it's possible to stop reading a file early
even when the generated comment is absent, since the generated comment
may no longer appear anywhere in the file. Begin parsing /* */ comment
blocks, which may span multiple lines, to be able to be able to detect
when we run into the first non-comment, non-blank text in the file.

It was mentioned in https://go.dev/issue/41196#issuecomment-686607452:

> [...] the primary focus for these comments is Go code
> and more generally Go package sources.
> Go package sources today can be Go, assembly, C, C++, Objective C,
> SWIG, and Fortran.
> The comment being discussed here, like the //go:build comment,
> handles all of these these except Fortran, which seems fine.

The initial scope of this package was to support parsing Go source only,
but it happens to work well with many other source types that are found
in Go packages. Replace mentions of "a Go source file" in documentation
and code with "a source file", to make it apply more generally. If this
will mean we need to parse comments differently depending on the source
type in the future, we can revisit this decision. Let's see how it goes.

Fixes issue 1.

Reviewed-On: https://dmitri.shuralyov.com/go/generated/...$changes/1

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.