Optimize reading bytes in guest

[austinabell]

There are a few things that seem a bit off, and I'm happy to separate any of these into new issues if enough different:

1. No no_std API for reading a dynamic amount of bytes in the guest

Currently, if you don't want to enable std, but want to use alloc to input a dynamic amount of bytes, you need to do something like:

https://github.com/austinabell/read_opt_repro/blob/10b2cc75c737695020abad46a81dc48c32f870a5/methods/guest/src/main.rs#L20-L32

Edit: using SYS_READ_AVAIL can't be relied on, since it only returns the length of data buffered, not total bytes.

As there is no safe API to read bytes. Ideally, a safe API to expose this such that a dev doesn't have to import risc0-zkvm-platform and handle this manually.

Also, not 100% sure of the implications, but avoiding many independent reads (currently seems like it defaults to reading 4 words at a time) might be more optimal for std as well to avoid many re-allocations and host function calls. Haven't tested enough around this yet, though.

2. read_slice is confusingly worded, as it doesn't allow for short reads. read_exact seems like a better name, to match the Rust std lib.

3. Somewhat an extension of 2, it would be ideal to have the functionality to do a short read and return how many elements were read.

The use case would be if you do not want to allocate, but know you have a bounded length of input. This way, you could read into a fixed buffer and be able to slice the range that is written.

I understand it might be a bit confusing since the read APIs are generic over Pod, so it might be a bit ambiguous in cases like [u32] if the usize returned would reference the amount of words or bytes returned, so would be nice to get input from others on this.

4. (more of a discussion point) I wonder if the APIs being generic over sth like BorrowedCursor to allow for reading to uninitialized buffers to avoid zeroing is a valid case to handle as the default before a pre 1.0 release. rfc link for std lib for related read APIs