When trying to yaml.Unmarshal a negative number into an uint, the
resulting error indicates an overflow with type information, but without
the position. For example:
> cannot unmarshal -23 into Go value of type uint64 ( overflow )
From an end user's perspective reading an error for an invalid YAML,
this is quite unintuitive. Especially compared to the error message when
trying to unmarshal a string into an uint.
> [1:4] cannot unmarshal string into Go struct field Foo.A of type uint64
> > 1 | a: 'foo'
> ^
This change has moved overflowError to internal.errors.overflowError,
implementing both the PrettyPrinter and Formatter. Its implementation is
uniform with those of the syntaxError and TypeError.
Thus, the error from above now looks like:
> [1:4] cannot unmarshal -23 into Go value of type uint64 ( overflow )
> > 1 | a: -23
> ^
The typeError previously located in decode.go now implements
PrettyPrinter, so it's been moved to internal/errors to be colocated
with the other PrettyPrinter errors.
When unmarshalling YAML and encountering an error in decoded that
results in a `yaml.typeError`, the error can't have the same nice
formatting because it doesn't implement the `errors.PrettyPrinter`
interface. This adds a field to the `yaml.typeError` struct that
specifies a token which is used in the implementation of the
PrettyPrinter interface. The tests were updated to instead match on
expected message substrings instead of full equality.
