Use scale-encode and scale-decode, and enable zero-copy decoding via Visitor trait

[jsdw]

Part of a series:

• scale-encode: new crate to handle encoding using type info.
• scale-decode: handle decoding using type info.
• !scale-value: update Value type to use scale-encode/decode.
• subxt: Start taking advantage of these in Subxt.

This PR:

• Leans on scale-encode to encode Values.
• Update Visitor impl in new scale-decode and ensure Value also impls DecodeAsType and DecodeAsFields/EncodeAsFields where appropriate.

The net effect of this is that Values share much of their encode and decode logic with every other static type now.

[niklasad1]

anything you want fix in this PR?

[jsdw]

I think this has been around a while, so I think it's fine; these u256/i256 types are a pain in general to work with!

(hiding whitespace in the github UI def helps given the space to tab change, sorry about that!)

[niklasad1]

maybe you do something like to fix the unwrap:

let mut it = values.values();
if let Some(v) = it.next() {
   if it.peek().is_none() {
       return inner_val.encode_as_type_to(type_id, types, out);
   } 
}
Err(Error::new(ErrorKind::WrongShape { actual: Kind::Tuple, expected: type_id }))

otherwise, just change it to an expect it easier to follow

[niklasad1]

👀

are you tired of tabs? :)

[jsdw]

It's mainly just that subxt, scale-decode and scale-encode all use spaces :)

But also, a really annoying thing I run into with tabs is making doc examples; I can't remember the exact issue but something like the IDE tries to make things tabs but cargo complains about tabs in doc comments; either way it all "just works" with spaces I guess (and spaces also seem to be the default anyway)

[niklasad1]

looks clean

[lexnv]

LGTM! Nice work! 👍