For example currently if result of decoding is expected to be unicode,
but is actually string the following confusing error is generated with
exactly the same have and want:

    --- FAIL: TestDecode/unicode(non-utf8)/"X\x01\x00\x00\x00\x93." (0.00s)
        ogorek_test.go:504: decode:
            have: "\x93"
            want: "\x93"

This happens because by default Printf("%#v") does not emit object type
even if it was derived type from builtin string - either our Bytes or
unicode, and emits the same string representation irregardless of which
type it is.

I think out-of-the box behaviour of %#v is unreasonable, but it is there
for a long time and so instead of trying to argue with Go upstream,
which after many years of arguing I think is not practical, teach our
Bytes and unicode types how to represent themselves under %#v with
indicating their type in the output.

After the fix the error from above becomes

    --- FAIL: TestDecode/unicode(non-utf8)/"X\x01\x00\x00\x00\x93." (0.00s)
        ogorek_test.go:504: decode:
            have: "\x93"
            want: ogórek.unicode("\x93")

which is more clear because want is different from have.

Adjusted behaviour is not test-only, because user applications might
want to do the same %#v at application level and there it would be also
confusing not to see a type.

/reviewed-by @kisielk
/reviewed-on https://github.com/kisielk/og-rek/pull/67