upgrade ndarray to 0.16

[nmandery]

This PR upgrades the ndarray dependency from 0.15 to 0.16

• I agree to follow the project's code of conduct.
• I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

---

[lnicola]

Thanks, but I don't think this is right (just as the previous code wasn't right). For reference, I saw this example in rust-ndarray/ndarray#994:

let a = Array2::<f64>::zeros([3, 4]).slice_move(s![1.., ..]);
let b = Array2::<f64>::zeros([2, 4]);
assert!(a.is_standard_layout());
assert!(b.is_standard_layout());
assert_eq!(a.shape(), b.shape());
assert_eq!(a.strides(), b.strides());
assert_ne!(
    unsafe { a.as_ptr().offset_from(a.into_raw_vec().as_ptr()) }, // 4
    unsafe { b.as_ptr().offset_from(b.into_raw_vec().as_ptr()) }, // 0
);

Which implies that slicing sometimes avoids copying the data by bumping an offset from the start of the storage (the example strips off the first row).

So the offset is not always 0 (of course, otherwise it wouldn't be there), and we should handle it, either by copying the data to a new Vec, or by introducing a similar offset concept, which would probably be quite confusing to use.

[nmandery]

I understood having a standard layout means also having an offset of 0, but I am afraid you are right. So we need to copy the data (like it is currently done for the non-standard-layout) in case of an offset.

I will add this to the PR later today.

[lnicola]

I'm again wondering if we should fully switch to ndarray (see #570).

[lnicola]

Let's also handle offset == 0 the same way.

[nmandery]

Done - I removed the if

[lnicola]

That might do an extra copy in the zero offset case.

[lnicola]

Suggested change

	data.into_iter().skip(offset).collect()
	data[offset].to_vec()

[nmandery]

Yepp, done

[lnicola]

@rouault looks like I've just won the lottery in https://github.com/georust/gdal/actions/runs/11372075639/job/31635584318:

OGR2SQLITE_Setup() failed due to sqlite3_api == nullptr