In golang/go#64488, we observe how a seemingly innocuous change to
postfix completion tests led to significant flakiness in our integration
tests, which started to encounter a new bug.Report for out-of-bounds
positions on type checker errors.

The root cause is that the new syntax of the test data triggered AST
fixes (i.e. parsego.fixAST) that overflowed the original file. The
failure was not deterministic because the postfix snippet tests do not
wait for diagnostics: adding an env.AfterChange() to the end of the test
body made the failure deterministic.

Additionally, while investigating I encountered and fixed a clear bug
that fixes (and therefore parsego.File.Fixed()) were not correctly
counted. This was incidental, and did not contribute to the test
failures. We don't actually use Fixed() very much, though we probably
should consider it more.

To fix the underlying bug, clamp positions to the token.File. This is
definitely unsatisfactory, but after an hour of tracing through the fix
logic, I am hesitant to commit to a more principled yet risky change.
This logic is rather tricky and clearly contains a lot of embedded
knowledge. It's probably best to leave it alone and redirect efforts to
improved parser recovery.

This is strong evidence that at some point we do need to carefully
scrutinize the AST fixes (see also golang/go#64335).

Updates golang/go#64335
Fixes golang/go#64488

Change-Id: I70a33c0c9aae66baae78e6474ee56cdaa25e45f4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/546655
Auto-Submit: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>