BaseBufferBuilder.isNull returns the inverse of the null state

### Describe the bug, including details regarding any error messages, version, and platform.

### Description

`BaseBufferBuilder.isNull(_:)` reports a value as null when it is valid, and as valid when it is null.

### Root Cause

The builders write a standard Arrow validity bitmap: `append` calls `setBit` for non-null values and `clearBit` for null values, so a set bit means valid. The function returns `isSet`, which means it reports the opposite of the intended result.

```swift
public func isNull(_ index: UInt) -> Bool {
return self.nulls.length == 0 || BitUtility.isSet(index + self.offset, buffer: self.nulls)
}
```

This is confirmed by two other places in the codebase that treat the same bitmap correctly:

- `ArrowData.isNull(_:)` returns `nullBuffer.length > 0 && !BitUtility.isSet(...)`
- `ListBufferBuilder.isNull(_:)` returned `!BitUtility.isSet(...)` (redundant override)

### Affected Builders

- `FixedBufferBuilder`
- `BoolBufferBuilder`
- `VariableBufferBuilder`
- `StructBufferBuilder`
- `Date32BufferBuilder` and `Date64BufferBuilder` (via `AbstractWrapperBufferBuilder`)

### Impact

No code inside the library calls the builders' `isNull` — all internal readers go through `ArrowData.isNull` — so this affects external users of the public builder API only.

Start at BaseBufferBuilder.isNull(_:) and compare its validity-bitmap handling with ArrowData.isNull(_:) and ListBufferBuilder.isNull(_:) as described. Verify the behavior across FixedBufferBuilder, BoolBufferBuilder, VariableBufferBuilder, StructBufferBuilder, and the date builders; done means set bits report non-null and cleared bits report null.

Written by the indexing model from the issue text.