Aravis: correct what the adapter reports, and handle cameras that lack features

[HazenBabcock]

Follow-up to #981. Two commits: the first fixes what the adapter tells
Micro-Manager about the image it is producing, the second stops it assuming
every camera has every feature.

What it reports

GetROI returned a garbage region. It assigned gx to both x and y,
and assigned both sizes to themselves. On a camera at 0,0 the first two values
happened to come out right, which is how this survived.

Dimensions and buffer size were only ever learned from a frame. Zero until
the first snap — MMCore sizes its circular buffer from them before that — and
stale after every change to the region or binning. Both now come from the
camera's region. Initialize also took the geometry from the width and height
bounds rather than the region, so a camera opening on anything smaller than
its maximum described every image it produced with the wrong dimensions.

Mono12 reported a bit depth of 10.

RGB8 came out with red and blue exchanged, and the alpha byte was never
written. MM's RGB32 is BGRA and its documentation says alpha should be zero;
rgb_to_rgba copied three bytes in source order and left the fourth holding
whatever the buffer held last.

PixelType carried two vocabularies, and really three — the camera's
GenICam name at Initialize, strings like "8bit mono" written from the image
path, and a setter that drove the camera. Now two properties: PixelFormat
(writable, the camera's names, selects the format) and PixelType (read-only,
8bit/16bit/32bitRGB, describes the buffer). That also removes something
#981 introduced, where the "Unknown" marker reached the format setter and the
adapter asked the camera for a pixel format called Unknown once per image.

What it assumes

Every capability the adapter used to assume is now asked once at Initialize.

The region is two questions. Aravis' region-offset probe reports on
OffsetX/OffsetY only, so a camera with a settable size and a fixed offset —
or the reverse — was wrong in both directions. Width and Height are now
asked for their GenICam access mode. ClearROI returns immediately on a fixed
camera, and no longer sets a 64×64 intermediate region first, which was
superstition (arv_camera_set_region already zeroes the offsets) and failed
outright on any camera whose minimum width is above 64.

SetExposure called set_frame_rate(-1.0) on every write — an error every
time on a camera with no frame-rate control — and read frame-rate bounds it
never looked at.

The binning increment is read through a guard. It is the step of the loop
that builds the allowed-value list, so an increment the camera cannot report —
which comes back as zero — never terminated.

This branch originally also replaced the binning property limits with a single
allowed-value list. 5145ff8 landed the same fix first, arrived at
independently, so that part is gone and this branch keeps that commit's version
verbatim; the increment guard is all that remains in that block.

numImages was ignored: asking for 8 frames delivered hundreds and the
sequence never finished. The stream callback now counts and ends the sequence
itself — it cannot call StopSequenceAcquisition, since unreffing the stream
joins the thread the callback runs on, so it stops the camera over the control
channel. It also stops on any InsertImage failure, which is what MMDevice.h
asks and which covers stopOnOverflow.

A camera whose formats the adapter cannot decode used to open anyway,
reporting zero bytes per pixel, which MMCore turns into "memory requirements not
adequate" the first time live acquisition starts. It now moves to a format it
can decode when the camera offers one, and refuses to open when it does not,
naming the formats the camera offered. Dropped formats are logged instead of
silently omitted.

ClearROI and SetBinning returned DEVICE_OK whatever happened. Both
report now, and both error codes have text — a user whose camera is switched off
gets a sentence naming the camera id rather than 3141.

The camera says who it is: vendor, model, serial number, device id and
firmware version as read-only properties.

Compatibility

Saved configurations that set PixelType to an Aravis format name will no
longer apply — they need PixelFormat. PixelType is read-only now, and its
values are the ones the other adapters use. This is the intended fix rather
than a side effect, but users will notice.

A camera offering no decodable format now fails to open where it previously
opened and then produced nothing. That is deliberate: the failure used to
surface later and somewhere else.

Testing

Eleven emulated camera profiles covering absent capabilities, mono depths, Bayer
and packed RGB, settable and fixed regions, binning, packed mono formats and
hardware triggering. Every check passes except camera_formats_all_advertised
on the two packed profiles, which is the packed-format support that comes next.

Also run against arv-fake-gv-camera, which ships with Aravis and has its own
GenICam XML — a camera implementation that is not mine, as a control.

Under AddressSanitizer: no errors, and no leak frame naming the adapter.

Not tested against physical hardware. The things I would most want a real
camera for are vendor GenICam quirks — <pMax>, <pInvalidator>, features that
go read-only during acquisition — and none of those are exercised here.