MMDevice AddTag/RemoveTag should be replaced

[marktsuchida]

These functions are used by multicam-like cameras to set metadata tags on the physical cameras that are auto-merged with the other tags generated by the physical cameras.

They are only used by multicam-like devices in order to set the xyz-CameraChannelIndex and xyz-CameraChannelName tags, where xyz is the device label of the multicam-like camera itself (also cf. #773).

There are multiple problems with this design:

• AddTag(key, deviceLabel, value) does not match with RemoveTag(key, value) — so the correct(?) usage of the latter is RemoveTag(deviceLabel + "-" + key, value). That's not actually done, leading to the tags kept set forever.
• Even if that were fixed, multicam-like cameras are not able to add/remove these tags at the right moments, which would be at the start and stop of sequence acquisitions.
• There was no reason why this had to touch the physical camera objects -- the information could be kept in the Core where it cannot be meddled (Do not copy AddTag() metadata in cameras #832) with.

The Core can instead support these tags properly:

• At the start of sequence acquisition, the Core queries camera's GetNumberOfChannels() and GetChannelName() to build a table. We need one more missing piece for multicam-like (but not lsm-like) cameras: GetChannelCameraPtr(), which returns the pointer to the physical camera.
• When an image is inserted by a physical camera, the Core maps the caller pointer to the correct index/name and adds the tags
• On AcqFinished(), the Core removes the caller pointer from its table (and rejects further images from that camera). When all cameras finish, the table is empty and the Core is ready for the next acquisition.

(This can potentially also serve as a finish-detection mechanism to fix #839.)

In the case of an lsm-like camera (see #838 for definition), the camera just returns its own pointer from GetChannelCameraPtr(), for every channel index. The Core enforces that channel camera pointers must be either all unique and different from the parent camera (multicam-like), or all equal to the parent camera (lsm-like). For lsm-like cameras, the camera should add the CameraChannelIndex tag. The Core can still add the CameraChannelName tag.

The above assumes we replace xyz-CameraChannel{Index,Name} (currently generated by multicam-like cameras) with just CameraChannel{Index,Name}. But various components depend on the former (with various levels of correctness: see #773 (comment)), so the Core can also add that back, at least for the time being. We should documente the label-prefixed tag as deprecated. Note that currently MMCoreJ adds the label-less CameraChannelIndex (but not CameraChannelName) using its own method that looks for Physical Channel {n} settings in the system state cache (which is unsurprisingly broken because the Teensy CameraPulser uses different property names).

This change, of course, requires bumping the device interface version.

[marktsuchida]

The Core should enforce metadata conventions by failing the acquisition.

• lsm-like cameras must generate CameraChannelIndex
• single-channel cameras, including when controlled by multi-like cameras, must not generate CameraChannelIndex
• no camera should generate the CameraChannelName tag (it's the Core's job)

These would be breaking changes, but we're already bumping the DIV here.

[marktsuchida]

Should we require multi-channel cameras to be a different device type? Or a different base class? Maybe not until we see a clear benefit. We'd probably need this if ever supporting multi-like cameras with differing image size/format per channel.