feat: Implement zeroed in the interpreter

[jfecher]

Description

Problem*

Resolves

Summary*

Implements zeroed in the interpreter

Additional Context

This is still a draft because I wanted to call attention to the inability to actually implement zeroed when the types may still sometimes not be known while interpretering. In this case we still don't want to fail since these zeroed values aren't meant to be used anyway - we'd rather return any dummy value. Here I've done it by adding Value::Zeroed but I think we should perhaps consider changing zeroed itself to return a dummy value of any type rather than one that is guaranteed to be some zero equivalent.

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[michaeljklein]

I like the approach with Value::Zeroed and think that it works well when considered as an unevaluated std::unsafe::zeroed::<T>() call.

I'm not sure how changing zeroed itself to return a dummy value of any type would be implemented. Do you mean that in the interpreter, std::unsafe::zeroed() would return Value::Zeroed?

[jfecher]

I'm not sure how changing zeroed itself to return a dummy value of any type would be implemented. Do you mean that in the interpreter, std::unsafe::zeroed() would return Value::Zeroed?

I mean changing zeroed to a different function to return a general stand-in value rather than necessarily zero. For example, returning a zeroed function is problematic. We could technically do it by returning FuncId(0) but this would be to some random function. A value of FuncId::dummy() would fit the current intent of the zeroed function more closely since it was meant to fill in values that wouldn't be used, such as a BoundedVec's unused elements.

[jfecher]

I'm also still unsure about the use of the new Value::Zeroed variant in this PR. It's very suboptimal since it'll likely lead to an error whenever it is eventually tried to be used as an actual value of its type.

On the other hand, we need to be able to call zeroed on non-zeroable types like functions to be able to wrap them in Options currently. It seems like a necessary evil to me and I can definitely see it poking its head into future errors.

[michaeljklein]

LGTM