Improved FLSliceResult management

[bmeike]

Refactor FLSliceResult to avoid the crazy mallocing

[bmeike]

This change affects a whole bunch of files. I don't think it is anything like necessary to read them all. Probably the C-language stuff is most important. ... and not the long_name_header_files, either.

Basically, what I've done is have the C code copy the native pointer and the length, that a FLSliceResult uses to frame a block of memory, directly into a Java object. It used to copy the FLSliceResult into the heap and give Java the pointer to the heap object.

Java never owns the block of memory that the FLSliceResult frames. It also doesn't malloc anything anymore. That means that it never has to free anything native, for a FLSliceResult.

Calls that used to take the pointer to the FLSliceResult (which had been on the heap) now take, instead, the pointer and length that used to be in the native FLSliceResult. Java just gets those things from its own FLSliceResult object.

[borrrden]

I understand that now you've decomposed slices into their respective parts when crossing the JNI boundary, in order to avoid the weird malloc, and introduced a Java class to hold them on the managed side. Seems fine!