smplx-build: fix witness type conversion in single-valued either type

[ikripaka]

• This PR suggests a bug fix and I've added the necessary tests.
• This PR introduces a new feature and I've discussed the update in an Issue or with the team.
• This PR is just a minor change like a typo fix.

---

1. PR fixes an error in include_simf! macro when handling single-valued Either or Option types in the Simplicity contract.

fn main () {
    let owner_sig: Signature = witness::SIGNATURE;

    match witness::PATH {
        Left(x: (Either<u16, u64>, Either<Option<bool>, Option<u256>>)) => {
            let (either1, either2): (Either<u16, u64>, Either<Option<bool>, Option<u256>>) = x;
        },
        Right(x: Either<u32, Either<u128, u8>>) => {
            let either1: Either<u32, Either<u128, u8>> = x;
        },
    }
}

include_simf! was incorrectly generating references for nested values in Option and Either<T, U>. After expansion, the generated code was failing because it passed &T value to Value::from instead of the owned T type.

impl simplex::program::WitnessTrait for EitherWithSingleWitnessWitness {
            #[doc = r" Build Simplicity witness values for contract execution."]
            #[must_use]
            fn build_witness(&self) -> simplex::simplicityhl::WitnessValues {

            //...
                  match &left_val.1 {
                            simplex::either::Either::Left(left_val) => {
                                Value::left(match &left_val {
                                    None => { Value::none(ResolvedType::boolean()) }
                                    Some(inner_val) => { Value::some(Value::from(inner_val)) }
                                }, ResolvedType::option(ResolvedType::u256()))
                            }
                            simplex::either::Either::Right(right_val) => {
                                Value::right(ResolvedType::option(ResolvedType::boolean()), match &right_val {
                                    None => { Value::none(ResolvedType::u256()) }
                                    Some(inner_val) => { Value::some(Value::from(UIntValue::U256(U256::from_byte_array(inner_val)))) }
                                })
                            }
                        }
            //...
            }
}

This PR updated the macro to generate explicit dereferences *inner_val, correctly passing the underlying values.

impl simplex::program::WitnessTrait for EitherWithSingleWitnessWitness {
            #[doc = r" Build Simplicity witness values for contract execution."]
            #[must_use]
            fn build_witness(&self) -> simplex::simplicityhl::WitnessValues {

            //...
                  match &left_val.1 {
                            simplex::either::Either::Left(left_val) => {
                                Value::left(match &left_val {
                                    None => { Value::none(ResolvedType::boolean()) }
                                    Some(inner_val) => { Value::some(Value::from(*inner_val)) }
                                }, ResolvedType::option(ResolvedType::u256()))
                            }
                            simplex::either::Either::Right(right_val) => {
                                Value::right(ResolvedType::option(ResolvedType::boolean()), match &right_val {
                                    None => { Value::none(ResolvedType::u256()) }
                                    Some(inner_val) => { Value::some(Value::from(UIntValue::U256(U256::from_byte_array(*inner_val)))) }
                                })
                            }
                        }
            //...
            }
}

Why this approach?
We can solve this issue without changing the interface in different ways
1) invoke .to_owned() on each path
caveats: double cloning
2) remove references on each match match &val {} -> match val {}
caveats: possible redundant object copying
3) include explicit dereference in needed places
By far, this is the most efficient way to fix the issue, as it avoids unnecessary types copying.

2. PR adds support for u1, u2, u4 and List types

[Arvolear]

Looks good! Let's fix other incompatibility issues here as well.

[Arvolear]

LGTM!