Improve STREAMs speed, unify with SEND/RECEIVE

[fachat]

The streams interface is horribly slow as it requires one kernel call per character for reading and another for writing. Previous attempts to speed up have not brought the necessary results (see the GETB/PUTB calls).

A new approach will be as follows:

• STRMAP: map a user space buffer to the receiving resp. sending end of a stream. A buffer can be more than 256 byte in length.
• STRPUSH / STRPULL to send resp. receive data into these mapped buffers, where only the number of bytes put to / taken from the buffer are exchanged as parameters, and the kernel copies the data between the user space and kernel space buffers

The buffer can be of different types:

• contiguous: like a single fread() resp. fwrite() to/from a single buffer
• circular: a circular buffer
• send/receive: STRPUSH and STRPULL are interleaved and a two-way send/receive communication is established

Advantages:

• (hopefully) better speed, e.g. lib6502 can map the full segment buffer and the only loop over STRPULLs on load. The filesystem can use a circular buffer, the kernel will translate.
• the buffer mapping is stored in the kernel and does not need to be re-calculated every time
• potential to extend to zero-copy transfers (but unclear yet how the remapping protocol will work)
• the send/receive code can replace the global SYSBUF/PCBUF mechanism, and related semaphore handling

Disadvantages:

• kernel/library size increases
• only a single task should allow to map a buffer (for resource reasons). the others (if any) still need to use the single-byte interface. Devices will also use the single-byte interfaces
• some sys calls /may/ require mapping the buffer on 256 byte boundaries (e.g. FORK) to avoid remapping in-between processing

Open issues:

• send/receive protocol not fully clear yet

[fachat]

This would be API-breaking if SEND/RECEIVE are gone then

[fachat]

See the GeckOS-NG-Buffers.adoc design document https://github.com/fachat/GeckOS-V2/blob/master/GeckOS-NG-Buffers.adoc

[fachat]

Note: plan to have this as a kernel addition in 2.2, while the actual breaking change will be in 3.0