Fix UB when interacting with Stream::Null(_)

[adri326]

The following test triggers UB on master, while using public-facing APIs:

#[test]
fn write_null_input_stream() {
    let mut machine = MachineBuilder::new()
        .with_streams(StreamConfig::in_memory())
        .build();

    let results = machine
        .run_query("current_input(Stream), write(Stream, hello).")
        .collect::<Vec<_>>();

    assert_eq!(results.len(), 1);
    assert!(results[0].is_err());
}

This PR fixes #2801, by:

• Ensuring that null streams aren't returned as null Cons (they instead return atom!("null_stream"), which is mapped to Stream::Null(Default::default()) in Machine::configure_streams().
• Turning the stream_as_cell! macro into an impl From<Stream> for HeapCellValue.
• Making it so that null streams can be written to (voiding the stuff written) and read from (always returning eof).

I left in the sanity checks used while debugging the issue, in case someone inadvertently creates another null Cons in the future.

[bakaq]

Heads up: Remember to #[cfg(miri, ignore)] tests that create a Machine. Currently they take forever and eventually fail anyway.

[Skgland]

(This is left as a draft since I have to take a flight this evening and I'm still unsure as to what the behavior of a null stream should be. Right now they cannot be read/written from/to, and errors are thrown)

I would expect a null stream to act like reading/writing to /dev/null

[bakaq]

I think that adding a test for at_end_of_steam/1 is also a good idea.

[bakaq]

This is not only an unexpected behavior for a null stream (at least if we are mimicking /dev/null behavior), but I think also plain wrong. When read, /dev/null is EOF, and that means that 0 bytes should be read (see docs). Here it means we should return Ok(0).

Returning Ok(buf.len()) means that the caller will think the buffer was filled (even though it wasn't) and use its data. buf is not necessarily zeroed before this call, and so may have garbled data from a previous use.