Alloc proc read buffer based on amount last read

[MasterDuke17]

Instead of using the suggested_size (which is almost always 65536
according to http://docs.libuv.org/en/v1.x/handle.html#data-types), use
the next power of two greater than the amount last read (which has been
added to the SpawnInfo struct).

Passes NQP's make m-test and Rakudo's make m-test m-spectest.

For https://gist.github.com/MasterDuke17/685b627a6a2749483dc5ec09c6a777a4
with only 5 iterations, compared to HEAD, heaptrack reports 654m "bytes allocated in total"
instead of 1.1g, 255m peak memory consumption instead of 387m, and on_alloc in
"most memory allocated" using 4.4m instead of 480m.

[ugexe]

Wouldn't this be obsoleted by further implementing $*DEFAULT-READ-ELEMS?

[jnthn]

Even if $*DEFAULT-READ-ELEMS were made to affect this some day, it'd still not provide automatic tuning as we achieve here. So I don't think it's either-or. (I'm not quite sure if $*DEFAULT-READ-ELEMS should affect this or not.)