Better implementation of `caller` instruction/operation

Current implementation of the `caller` instruction and support infrastructure has some limitations and may potentially be optimized to reduce the number of columns by 4.

First, the limitation of `caller` instruction (and the underlying operation) is that we can call it only in `syscall` context. It would be useful, however, to call it in other contexts as well.

Second, to support the `caller` operation, we add 4 columns to the system trace to keep track of the hash of the currently executing function. We also add `in_syscall` column to determine whether we are in a `syscall` or not. The `in_syscall` column is used for two primary purposes: (1) to figure out whether we can invoke the `caller` operation, and (2) whether we can invoke a `syscall` operation.

One potential way to simplify and improve this structure is to give special meaning to memory address $0$ in every context. Specifically, this memory address would hold the hash of the currently executing function. This would be instead of storing this value in the 4 columns of the system trace, and thus, we could eliminate 4 columns from the main trace.

To populate address $0$ with the hash of the currently executing function, we would need up update the logic of `CALL` and `SYSCALL` operations. These operations would now need to write the hash of the called function into memory. Thus, the operations would need to perform the following requests to the chiplet bus:
- `CALL`: 1 hasher request and 1 memory write request.
- `SYSCALL`, 1 hasher request, 1 kernel ROOM access request, and 1 memory write request.

I believe both of these should be fine as we still have some slack in constraint degrees involving these operations.

Next, we'll need to ensure that memory address $0$ is "read-only". This can be done by adding extra constraints to the operations which write to memory to make sure the address is in the valid range.

Finally, we'd need to update the `CALLER` operation to read memory address $0$ from the parent's context. To track the parent context, we'll need to add one column to the system trace - e.g., `prnt_ctx`. This column would be initialized to $0$ and would be updated by the `CALL` and `SYSCALL` operations.

With the above design we gain the following benefits:
- We can execute `caller` operation in every context (not just in syscall).
- We can also get the value of the currently executing function in every context.
- We reduce the number of columns by 3.

We can also probably get rid of `in_syscall` column. First, this column is no longer needed to check the validity of `caller` instructions. But we still need it to make sure `syscalls` can be made only from non-syscall contexts. We should be able to do this by enforcing that $ctx != 0$ whenever `SYSCALL` operation is executed. This constraint may require a helper value (inverse of $ctx$) - but i think we should be able to find a place for it.

Overall, if the above changes can be implemented, we'd reduce the size of the system trace from 8 columns to 4, and the new system trace layout would like like so:
```
clk ctx prnt_ctx fmp
├───────┴───────┴────────────┴────────┤
```