Semantics of sdepth, and information about current stack state

Tangentially related to #1744, I have two (three?) issues with some details around the operand stack and related instructions:

1. The `sdepth` instruction is virtually useless, as it doesn't tell you the actual depth of the operand stack unless the stack is deeper than 16 elements. Not only does this instruction not do what it says it does, it is really only useful for one thing AFAICT, implementing `std::sys::truncate_stack`. Why does it not produce the actual depth of the operand stack?
2. Similarly, it is not clear to me why asking the processor for the current state of the stack should include all of the default-initialized elements so that the underlying data structure has `MIN_STACK_DEPTH` elements. It doesn't make any sense to _ever_ return stuff that wasn't pushed/produced by an instruction. If there are exceptions to that within the processor, that feels like it should be an internal detail, not the way the public API works (e.g. `Stack::get_state_at`, the various methods of `StackOutputs`). I'm also not clear on _why_ the operand stack always requires 16 elements (obviously its representation in the trace might always require 16 elements, but that feels like a completely internal implementation detail). From the perspective of a user, an operand stack coming out-of-the-box with 16 zeros in it, isn't helpful. Further, I suspect this is causing us to use the overflow table when we definitely do not need to be (i.e. if I run `push.1 sdepth` in the playground, it returns `17`, which tells me that one of the default-initialized slots got pushed into the overflow, with no way to avoid that, because `drop` on the default stack doesn't have any effect).

In particular, I find 2 frustrating, as in the debugger I found it impossible to reason about the operand stack state at any given cycle of a non-trivial program - you get a bunch of zeroes, maybe some of them are real values, maybe some of them are just the default-initialized values that were on the stack at the start, it is at best misleading.

Additionally, I think this actually can hide nasty bugs. Consider the following:

```
begin
dropw
dropw
dropw
dropw
dropw
end
```

Running this in the playground _succeeds_, even though it quite obviously should fail with an error about exhausting the operand stack.

I'm sure there is a reason the current behavior is what it is, but I'd to discuss how we can address at least the two issues I listed above, as they represent bugs IMO. Whether `drop`ing more than 16 elements should cause a trap is a different issue, although I think it too represents a bug.