Recheck mark stack for objects after scanning fibers

When we scan stuff like finalizers etc. it can happen we end up pushing
a new object into the mark stack due to the write barrier when
a concurrent mature mark phase is also in progress.

By rescanning this as well in the loop we make sure we handle all
objects for which this might happen.
Don't use iterator to walk vector that can grow

Problem here is that walking this mark set can result in new entries
being added. This can happen because the write barrier runs for objects
that are seen and this can add elements.

The new entries added can result in a vector resize and that invalidates
all the iterators. This way we prevent this problem.
Always use a minimal size of 1 for ByteArray even if 0 is requested

Methods that work with ByteArray's usually expect to be able to set
things like the last byte to 0. Especially some of the C-API methods
use that. This prevents issues when something creates a ByteArray
of size 0.

Fixes #2657
Initialize ByteArray with room for 0 bytes
Update packing from Rapa
Update test reflecting not creating 0 sizes ByteArray's