runtime: Workaround read-bytevector! bug on x86-32

Under the following circumstances we may be unable to catch an exception
thrown by a native function:

- The target platform is x86-32

- tailcallopt is enabled with llc and an explicit tail call is placed in
  the right place in the call chain.

- The stack is large enough. Removing arguments from the native function
  or optimising out the (let)'s SEL (as in -O2) causes the catch to
  succeed again

This has the hallmarks of a possible LLVM bug. x86-32 uses a different
calling convention for tail calls and it's not as well tested as the
default calling convention. It's unsurprising it could have bad
interactions with exception handling.

To work around this we can move the native-read-bytevector! definition
from a (let) to a top-level (define). This reduces the depth of our call
stack at -O 0 and allows the exception to be caught again. It also
generates significantly better code on all platforms at -O 0
runtime: Fix huge heap waste on _LLIBY_ALWAYS_GC

The _LLIBY_ALWAYS_GC logic to force a GC cycle was happening at a very
low level. Whenever a new memory segment was allocated it was
immediately sealed by setting its "next" pointer to its "end" pointer.
The intent was the force program to re-enter the runtime for the next
allocation and force another GC cycle.

However, this had the side effect of forcing every cell being moved to
the new heap during garbage collection to allocate a new segment. This
was compounded by the fact that segments allocated from the same heap
use successively larger allocations up to 1MiB. The result was nearly
every cell moved during garbage collection will use 1MiB of virtual
memory and 4KiB of physical memory. This is pathologically wasteful and
quickly exhausts virtual memory on 32bit platforms.

Instead of sealing a segment from allocations after it's first allocated
instead seal it before returning control back to the program. This
allows the segments to be completely used during garbage collection
while still forcing a GC on every allocation.
runtime: Remove unused <iostream> include

This was probably left over from std::cout debugging
runtime: Root the input port in (read)

DatumReader can allocate. Ensure we root the port to prevent it from
being garbage collected and the stream deleted. This happened to work
before due to a lucky memory layout but the recent segement allocation
changes surfaced the problem.