encoding/json/v2: investigate replacing jsontext.Internal symbol

[neild]

The draft encoding/json/jsontext package includes an "Internal" symbol used to expose internal implementation details to encoding/json and encoding/json/v2.

This is awkward and not something we've done in the public API of a package in the standard library before. We should avoid it if we can, even if that means some additional inconvenience for ourselves. Possibilities might include an additional internal package and/or //go:linkname shenanigans.

[dsnet]

One option is to move most of the logic in jsontext to an internal jsontext package and forward the public API via type aliases in the public jsontext package. This technique would work, but would result in a poor user experience. In particular, none of the methods nor any of the struct fields will be reflected on the godoc for the public jsontext package. Perhaps there should be a way to indicate on a type alias that we intend for the documentation to be forwarded? (Perhaps a combination of the fact that it references an internal package and lacks any doc comments?)

\cc @jba

[dsnet]

Discussed in the v2 working group.

I will investigate eliminating the Internal hack by placing the implementation of jsontext into a package like encoding/json/internal/jsontext, while dropping the relevant aliases in encoding/json/jsontext. We will see what it would take to get pkgsite (and probably go doc) to render documentation with aliases more nicely. In particular, showing the type declaration itself and any methods on the type.