Serde Encode Options

[lovromazgon]

This introduces encode options in Serde.Encode and related functions. There are currently two encode options, ID and Index. I reused the existing Index option and adjusted it to function both as SerdeOpt and EncodeOpt.

The caller can now explicitly specify an ID and index when encoding an object, which overrides the default behavior of choosing the encoding function based on the type of the value being encoded. The primary motivation behind this is to support the encoding of dynamic data stored in a map by explicitly choosing the schema for encoding it. Besides that, it could also be used to register multiple schemas/encode functions for the same type and explicitly choose which one to use based on the ID.

It also fixes some minor bugs:

• When registering a schema without supplying DecodeFn, Decode now returns ErrNotRegistered
• When using DecodeNew on a schema without an associated type it now returns ErrNotRegistered instead of a panic

Related to the discussion in #453.

[twmb]

Mind changing this PR to what we've agreed on in #467 (comment) ?

[lovromazgon]

I created a separate PR that includes those changes (#506). It is mutually exclusive with this PR, both kinda do the same thing, but with different approaches. The new PR is based on your comment that we don't necessarily need to separate RegisterOpt and EncodeOpt. I'll try to articulate what benefits and drawbacks I see for each approach and leave it for you to decide which one you prefer.

Having separate RegisterOpt and EncodeOpt (i.e. this PR) allows us to prevent the user from sending ID into Register, as that function already expects the ID as a normal argument. In the new PR I had to decide what to do if that happens (see these lines). Options ID and Index also need special treatment in function Encode, as they are not applied on tserde, but rather they decide which tserde to use. In this PR this is solved by having a struct that is mutated using EncodeOpt. In the new PR options ID and Index are separated from all options and treated separately (see this function). The internals of the new approach seem a bit hacky, although for the caller it might be simpler and more flexible to have only one set of options that can be passed both to Register and Encode (possibly also to Decode, see this comment).

Let me know what you think and feel free to close one of these PRs, I'll then focus on the one that's left.

[lovromazgon]

Hey @twmb, hope you're well! I was wondering if you had any updates on the PRs? I haven't received any response and I just wanted to make sure everything is okay. Let me know if there's anything I can do to help. Thanks!

[twmb]

I'm going to focus on 506 first (which I think includes some of this) and have some thoughts about the EncodingOpt additions to the Encode functions -- I've come to a thought a few days ago that I think we should essentially double the encode functions. I think variadic options for every individual encoding function is a bit odd and way more extensive than any encoder I've seen. I wonder if we can either have a new extendable struct their (a la slog's NewEncoder functions) or if we can have two APIs (Encode, EncodeWithOpt).

[twmb]

Finally left my comment on 506 -- also can 506 be rebased on the latest / resolve the TODOs about the header PR?

[twmb]

Closing in favor of continuing this in #506