Preserve semantic options in Encoder and Decoder

[dsnet]

A jsontext.Encoder and jsontext.Decoder could be constructed with semantic options (e.g., json.Deterministic) where such options are ignored for all encode/decode specific operations.

However, allow semantic options to take effect when such an Encoder or Decoder is passed to MarshalEncode or UnmarshalDecode. The semantic option can still be overridden.

One reason for this behavior is for easier migration. For example, this v1 code:

dec := jsonv1.NewDecoder(in)
dec.DisallowUnknownFields()
for {
	... := dec.Decode(...)
}

can be migrated as:

dec := jsontext.NewDecoder(in,
	json.RejectUnknownMembers(true))
for {
	... := json.UnmarshalDecode(dec, ...)
}

Notice that RejectUnknownMembers does not need
to be repeatedly passed to every UnmarshalDecode call because it is implicitly stored on the Decoder.

The alternative behavior is to have the construction of an Encoder or Decoder explicitly drop any semantic options. However, this seems like extra work for no benefit.

[mvdan]

I think this is reasonable and consistent.

[dsnet]

If we go with this change where we embrace the possibility of jsontext.Encoder or jsontext.Decoder to be able to store semantic options, then we should seriously consider @willfaught's suggestion of dropping an json.Options argument from the json.MarshalerTo and json.UnmarshalerFrom methods and instead expose an Options() json.Options method on Encoder and Decoder`.

[johanbrandhorst]

I like it

[johanbrandhorst]

If we go with this change where we embrace the possibility of jsontext.Encoder or jsontext.Decoder to be able to store semantic options, then we should seriously consider @willfaught's suggestion of dropping an json.Options argument from the json.MarshalerTo and json.UnmarshalerFrom methods and instead expose an Options() json.Options method on Encoder and Decoder`.

I like this too, if the options stick to the encoder/decoder, why have them as an extra argument? That seems like it would indeed just introduce confusion.