[BUG] `DType::from` rejects `S16`, `U16` and `F16`

[`src/core/util.rs:76-81`](https://github.com/arrayfire/arrayfire-rust/blob/master/src/core/util.rs#L76-L81):

```rust
impl From for DType {
fn from(t: u32) -> Self {
assert!(DType::F32 as u32 <= t && t <= DType::U64 as u32);
unsafe { mem::transmute(t) }
}
}
```

The upper bound is `DType::U64`, which is **9**. But the enum continues past it ([`src/core/defines.rs:112-139`](https://github.com/arrayfire/arrayfire-rust/blob/master/src/core/defines.rs#L112-L139)):

```rust
U64 = 9,
S16 = 10,
U16 = 11,
F16 = 12,
```

So the assert fires for three of the crate's own supported types. `Array::get_type()` (`array.rs:427-432`) is the caller, which means:

```rust
let a = randu::(dim4!(3, 3));
let t = a.get_type(); // panics
println!("{:?}", a); // panics — Debug impl calls get_type()
```

This is not a version-skew problem — it's wrong against a correct 3.8 library, and has been since f16 support was added. It's also the inverse mistake to the one in `AfError::from`: that assert is too loose, this one is too tight.

**Fix:** bound at `DType::F16 as u32`, or better, use an exhaustive `match` with a clear error for unrecognised values. Note ArrayFire 3.10 adds `s8 = 13`, so a `match` would future-proof this.

---

Found by Claude Opus 5. Verified manually.

Start with the DType conversion in src/core/util.rs:76-81 and compare its accepted range with the enum in src/core/defines.rs:112-139. Trace Array::get_type() in array.rs:427-432 and verify that S16, U16, and F16 no longer panic, including when Debug formatting an array; unrecognised values should have a clear failure.

Written by the indexing model from the issue text.