Closes #21

Supports unnamed and named composites and variants:

use scale_value::value;

let val = value!({
    name: "localhost",
    address: V4(127, 0, 0, 1),
    payload: {
        bytes:  (255, 3, 4, 9),
        method: ("Post", 3000),
    },
});

Values can be nested in each other:

use scale_value::value;

let data_value = value!((1, v1(1, 2), 3));
let val = value!(POST { data: data_value });

Trailing commas are optional

In a lot of places I replaced code in tests with the macro which also gives us a good check that everything is working fine. There is only one thing that is not working yet, but it should be rare anyway: keys in named composites that have spaces in them.

It would be good to be able to display the structure of the type if debug formatted so that people can see how they might match against the structure.

This PR ensures that nested tuples inside sequences can be encoded properly.

Prior to this encoding a Vec<(u8, u16)> would not work properly with dynamic values of

Value::unnamed_composite(
        vec![
            Value::u128(3u8.into()),
            Value::u128(1u16.into()),
        ]
    );

This is because find_sequence_candidate function did assume that the last type of the value is the "end-type" of the sequence.

Instead, if we deal with tuple/composite inside a sequence (sequence or array otherwise), then recurse back to encode_composite with proper parameters (unflattened).

Detected by: https://github.com/paritytech/subxt/issues/982.

// @paritytech/subxt-team

These types currently exist because they exist in scale-info, but I expect they aren't super commonly used (?), and think it would be more ergonomic/simplify the code a bit to deserialize anything matching that type into a Composite::Unnamed (ie a Vec<Value<T>> where each value is a Primitive::U128 (unsigned number type).

This type is obviously much larger and no longer allocation free, but comes with a couple of advantages:

• we can remove some of our special handling that has to look at composites or U256/I256 values when encoding/decoding from sequences.
• currently, if you serde::serialize a U256/I256 it'll serialize into a sequence of bytes, but then if you try deserializing that sequence of bytes again you get a Composite::Unnamed back (it's the catch-all sequence deserialize target). Removing U256/I256 leaves us with exactly one sequence target and so no ambiguity, so things can go back and forth without any issue).
• U256/I256 types can't be nicely worked with in rust anyway, so having a special case for them feels slightly odd. If they are super common then having a special case makes sense, but otherwise I don't think it does.

(side note: bit sequences are just vectors of bools; does it makes sense to also "de-optimise" those and remove the special BitSequence type?)

cargo-contract has a format called SCON (https://github.com/paritytech/cargo-contract/blob/master/src/cmd/extrinsics/transcode/scon/parse.rs) that runtime values can be parsed from and to. We could add something like this here behind a feature flag.

Take inspiration from the above, but offhand I'm thinking something like:

• Numbers like 1234 or 1_234_567 or -1234 or -12_345 parse into our U128/I128 primitives.
• Strings in double quotes with \" to escape any inner double quotes and \\ to escape the backslashes? may want to support \n, \t and such too?
• chars in single quotes eg 'a', 'b'.
• true and false for bools.
• named composites can encode to something like { name: 1_234, other: false }. Could accept double quotes around field names to accept arbitrary strings eg { "a weird name": 1_234, other: false } (though I wouldn't expect names that weren't compatible with rust struct field names).
• unnamed composites can be tupleish like (1_234, false). Could accept square brackets, but I like how this relates/works nicely when used as variants too (see next point), so would be inclined not to.
• named and unnamed variants could be as above but preceeded with variant name eg MyVariant { name: 1_234, other: false } or MyVariant(1_234, false).
• bit sequences could be something like <110101011001>? These will be uncommon I'd guess, and bool composites will encode to types expecting bit sequences anyway, so <001> would SCALE encode (but not serialize) the same as (false, false, true).

After reflecting on #31, I thought it might be better to try and simplify the method that we use to encode Values.

Previously, we'd immediately try to unwrap things that looked like newtype wrappers from the TypeInfo and in most cases from the Value. Things like sequences cause us issues here; a sequence of 1 value looks just like a newtype wrapper. Another issue here is that we've changed things before we ever try to encode, and so it was found that some Values which perfectly aligned with the intended TypeInfo already were rejected.

Now, when we encounter a composite type we will:

1. Try to encode everything as-is without changing anything. This ensures that if the user provides a Value that lines up with the expected target type, it should always encode successfully.
2. If that fails, remove any "newtype" like wrappings from the TypeInfo we're targeting and try to encode our Value to that. if the Value has already ignored all newtype things, this should now work
3. If that fails, unwrap one layer of the Value at a time (as long as we have layers that look like possible newtype wrappings) and try to encode again until we have nothing left to remove. This is the slowest path, since we will try encoding more than once at different depths, but is our best effort to find some version of the provided Value that lines up with the encode target.

If nothing is successful, we'll always return the error from 1 so that it makes sense given what the user provided.

These parsers are available via scale_value::stringify::custom_parsers and allow hex and ss58 addresses to be correctly parsed as part of a string Value.

We add an "escape hatch" to allow users to parse custom strings into Value's in addition to the usual parsing logic. This allows custom logic to be inserted to cover specific cases, like parsing from hex strings or ss58 addresses.

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.

We've consolidated bit sequence handling into the scale-bits crate, so lean on that and remove encode/decode logic from here.

Also add a CI check that we can compile the crate to WASM.

And for the sake of expediency I've also prepped for the next release.

Closes #2

This moves the decoding logic out into a separate crate, scale-decode.

(As a side effect I slightly simplified how compact values are decoded to remove some nesting, since it felt unnecessary.)

Currently we can decode things using V14 metadata, since V14 metadata contains the necessary type information.

Pre-V14, I think we need to support type-mapping information (which maps from type-name as seen in metadata to something we can understand. Each pre-V14 metadata differs a bit, and so we may end up needing some wrapper TypeRegistry<'a> sort of type that a &PortableRegistry can be converted into easily, and pre-V14 metadatas + type mappings could convert into also.

Desub has some logic for this already to decode blocks, so hopefully we could borrow or draw inspiration form how that works.

I suspect that adding this support could be rather complex and time consuming, so we need to weigh up whether it's worth while, and if so, should do a preliminary investigation into how complex/time-consuming before embarking on any actual work.

Currently we support decoding and encoding into U256/I256 variants, but both are just represented as arrays of bytes.

Serializing values containing U256/I256's via serde isn't great; they serialize into byte sequences. Deserializing those leaves you with composites; no deserialize input can get out U256/I256; so unlike other types, they don't convert back and forth nicely.

With #7 we cannot yet stringify U256/I256 and we cannot parse strings into them. Parsing isn't as important (we get back a nice error if a numeric string is too big to fit U128/I128) but calling .to_string() on a value containing a U256/I258 will panic. Whatever we stringify should be parsable back again, so we need to add both or neither.

So, do we:

1. figure out how to parse and stringify U256/I256 (my vote; accept numeric strings and parse them into the smallest of U256/I256 or U128/I128 that they will fit into), or
2. remove support for U256/I256 entirely, since they are, from what I gather, unused on the whole (see https://github.com/paritytech/scale-info/pull/25 for history). Etherum needs them, but parity-scale-codec doesn't support encoding/decoding into them, and without manual TypeInfo impls they will never be seen in metadata.