Why

With the current Decode/BorrowDecode, it's impossible to implement them on a type that borrows something other than the input data. A concrete example would be a Vec<'bump, T: 'bump> which is allocated by an arena allocator.

How

This PR introduces the following changes:

• Add a decode function that accepts a decode context: decode_from_slice_with_ctx<Ctx, D: de::Decode<Ctx>, C: Config>(src: &[u8], config: C, ctx: Ctx). In that arena Vec example, the decode context would be the allocator &Bump.
• The context is attached to DecoderImpl and exposed to Decode implements via Decoder::ctx method.
• Decode trait is changed to Decode<C>, which allows types to implement Decode only under some specific context. (Vec<'bump, T: 'bump> would implement Decode<&'bump Bump>)
• The derive macro Decode is changed to generating impl<Ctx> Decode<Ctx> for ... instead of impl Decode for .... A container attribute decode_context is added to allow deriving Decode with a concrete context type. (for example #[bincode(decode_context = "&'bump Bump")])
• All changes above are also similarly done to BorrowDecoder.

You can see how these changes work together in tests/ctx.rs.

I know this is a big change and would break existing 2.0.0 users. But it's still rc so I guess it's not too late to discuss it? ;)

Alternative Design

Leaves (Borrow)Decode untouched, and add (Borrow)DecodeWithContext<C>.

Pros:

• Less impactful. Non-breaking to (Borrow)Decode.
• Less cognitive overload to implementors who don't care about decode contexts.

Con:

• Trait explosion: v2 release candidate initiative to include stateful decode impls akin to serde's DeserializeSeed? #578 (comment).
• Needs a separate derive macro.

TODOs

This PR hasn't been polished to a mergeable state yet. I will do that if the overall design is accepted.

• Namings are not consistent (C?Ctx?Context? )
• Docs not updated
• virtue is updated to allow generating impl<Ctx>. This would need a separate PR.
• Current derive macro Decode allows Ctx to be either a concrete type or totally unbounded. How about allowing Ctx: ...? Is it useful enough to be implemented?