Improve errors for type conversion failure especially at contract function boundary

[leighmcculloch]

When folks implement their contracts, they specify their types and there's an assumption that callers will always pass the correct types.

For example, in the following contract function a single parameter is expected to be a u32:

#[contractimpl]
impl Contract {
    pub fn doit(thing: u32) {
        // ...
    }
}

Indeed the tooling does a lot to make sure that clients do indeed pass a u32. Generated clients for Rust contracts expose typed calling functions that will only accept and send a u32. Generated bindings for TypeScript dapps expose typed functions. Even the Soroban CLI knows what types are required on the command line because it interrogates the contract interface (spec) to know what is required.

However, its also possible for contracts to call other contracts directly, ignoring any well defined interface. Anyone implementing the custom account interface will need to unpack their signature and that's not something currently captured and generated into bindings. There are also cases where conversion occurs reading things from storage and human error results in the wrong type being expected.

Some of those cases will be improved over time, but there's always going to be cases where a type is expected, the wrong type of value is provided, and an error occurs.

Today that error looks like this:

VM call trapped: UnreachableCodeReached

Ref: https://discord.com/channels/897514728459468821/1225612987381841993/1225652824252354602

The error isn't specific or useful. When a function has a few parameters, and does a few conversions within, it can be difficult to know or debug where the problem has occurred.

We've talked about this a few times in different forums, but we need conversion failure to generate some sort of diagnostic log that indicates, attempt to convert to X, but got Y which doesn't convert. For contract function parameters too we also have the opportunity to add an additional log that states the function being called, as well as which number parameter it is that failed to convert.