ByteBuffer allocator should use malloc_good_size() on Darwin

[weissi]

Darwin has a useful function malloc_good_size() which returns a good size to malloc. ByteBuffer's allocator should use that instead of just rounding up to the next power of 2.

The malloc_good_size() function rounds size up to a value that the allocator implementation can allocate without adding any padding; it then
returns that rounded-up value.

On Linux, we should also have a better strategy.

[natikgadzhi]

Halp! We could:

1. Just patch the current _Storage behavior to respect malloc_good_size instead of next power of 2 on Darwin — prop fine, but adds a discrepancy of allocation strategy between platforms, and ditto for Linux.
2. Make _Storage swappable and implement _DarwinStorage or something that kicks in on, well, Darwin. I don't understand how that is a good idea — Storage is internal anyway, so it's not like our users can swap it out for their own alloc strategy storage.
3. Make ByteBufferAllocator responsible for realloc, and therefore be able to decide how much to allocate. Document how to make alternative ByteBufferAllocators, and see which APIs we would have to patch to allow people to plug in their allocators if they wish to (i.e. make buffers from files, etc etc). Or perhaps I'm overthinking it.

Feels like these are solutions in search of two different problems, and you just want pt 1 of this, right? Defer the whole Allocator conversation to #2729 (comment) and just make things slightly more memory efficient here?

[Lukasa]

Yeah, I think this just wants the part 1 bit.

[natikgadzhi]

Ok. The smallest first step that I can get in a PR is using malloc_good_size on Dawrin in the existing _Storage, and get this merged.

Step 2 could be to extend this and use some combination of posix_memalign and malloc on Linux. Problem here is that if we wanted to just plug posix_memalign or aligned_alloc, we would have to use that instead of malloc, and therefore we would have to figure out how to swap out ByteBufferAllocator. This sounds like a broader conversation.