arrow-array ffi: FFI_ArrowArray.null_count is always interpreted as unsigned and initialized during conversion from C to Rust.

[pianoyeg94]

Describe the bug
The Arrow C data interface spec states, that the null_count field of an ArrowArray structure instance
"MAY be -1 if not yet computed" .
Currently the arrow-array crate's ffi always treats this field as unsigned and initialized, though this assumption can be
false, if the arrow C data interface specification is strictly followed. Because of that one can get all sorts of nasty bugs
when working with arrays coming from C.

To Reproduce

1. Construct an instance of an FFI_ArrowArray and set its null_count field to -1.
2. Convert the above instance into an ArrayData instance with the help of the from_ffi
   (or from_ffi_and_data_type) function.
3. Call the null_count() method on the resulting ArrayData instance (calls into NullBuffer's null_count()).
4. The result is a usize::MAX due to conversion from signed to unsigned.

Expected behavior
If the null_count field of an FFI_ArrowArray instance is -1 (uninitialized):
- Either initialize the null_count field of a NullBuffer instance during ffi conversion by inspecting the null buffer itself,
- or stick to the arrow C data interface spec, by making the null_count field of theNullBuffer an Option and adding
support for lazy initialization during the call to its null_count() method.

[tustvold]

Computing the null count if not provided makes sense to me, various kernels rely on this being precomputed to efficiently perform kernel selection and so changing this would be highly disruptive

[adbmal]

take

[alamb]

label_issue.py automatically added labels {'arrow'} from #6674