scan_zfs.so, a second backend behind the llapi_scan_device() entry point
from LU-20606. It reads a Lustre on ZFS MDT or OST dataset through
libzpool and emits the same llapi_scan_rec to the same sink, with no
mounted Lustre server.

What already exists

A working prototype, 605 lines to the ldiskfs scanner's 693, verified
against an MDT built by osd-zfs itself: 87,600 objects per second single
threaded, 274,000 at 24 threads, identical output at every thread count.
Its unit of work is object ID ranges, which is what the backend ABI
already chunks by.

Packaging

The same shape as mount_osd_zfs.so, which is built under ZFS_ENABLED and
PLUGINS and already links
```
-lzfs -lnvpair -lzpool
```

Scope

MDT and OST datasets, read only, snapshot by default. The same record,
demand mask and cost tiers as the ldiskfs backend. Target and local
resolution for ZFS targets in lfind. Not repair, and not the in kernel
OSD path, which is 2.19 work.

To settle first

Every run measured so far snapshotted, exported, then scanned. Running
lfind on a serving MDS is the imported pool case, and that one is not
proved. Either a snapshot of an imported pool reads cleanly through
libzpool, or ZFS targets need the pool exported first, and that changes
the interface rather than only the code.