Rename multiplier to exposures_per_event and move to first dim of shape

[thomashopkins32]

This PR does the following:

• Renames multiplier -> frames_per_event
• Add the frames_per_event as the first dimension of DataKey.shape
• Ensure that the index provided by DetectorWriter.get_indices_written() and DetectorWriter.observe_indices_written() is divided by frames_per_event so that it actually captures the correct amount of exposures in each index (except for PandA which explicitly says it only has 1 "frame" per event)
• Add unit tests showing that describe() works as intended
• Add unit tests showing that stream resources are actually batches of exposures
• Re-order self._writer.open() and self._writer.get_indices_written(). The writer needs to be opened in order to get the indices written. Otherwise, it has no idea what frames_per_event to use when returning the index last written.

I could not actually add tests using bluesky plans and inspecting the data afterword because TriggerInfo is hardcoded in StandardDetector. I think it is a separate issue that should be raised since it would enhance the scope of this PR. I will open an issue for this soon and mention it below.

Otherwise, I have a few open questions regarding my understanding of ophyd-async as well as the implementation which I will also leave as review comments. Please see below.

Closes #576
Closes #431

[jwlodek]

Tested w/ the sister bluesky PR, in a variety of cases, and they all seem to work. @coretl OK to merge?

[coretl]

Tested w/ the sister bluesky PR, in a variety of cases, and they all seem to work. @coretl OK to merge?

Just discussed in the collab call, and there was widespread concern about what else might break when these descriptors change from [] to [1]. @genematx also raised a point about 1D arrays that I didn't understand, so I think we need more discussions with @danielballan before we merge. Maybe we discuss at next collab call?

[thomashopkins32]

@jwlodek @coretl @genematx Please review the change of default behavior for single scalars, then we should be good to merge.

Although either [1] or [] are acceptable to use in the descriptor, the default will be [].

One final question is whether to say whether the dtype is a "number" or "array". As of the most recent commit, only [] and [1] are considered a "number" while everything else is an "array".

[genematx]

Thank you, @thomashopkins32. LGTM!
I think how you treat dtype is consistent with what we had before, although we don't even use it in Tiled (dtype_numpy is very important though).

[thomashopkins32]

@jwlodek @coretl Are we good to merge this PR?

[coretl]

Fine to merge from what I can see, but I'll leave final approval to @jwlodek

[jwlodek]

Just tested w/ two cameras, and it looks good:

In [11]: arr = tiled_client.values().last()['primary']['external']['manta-cam1'].read()

In [12]: arr.shape
Out[12]: (100, 544, 728)

In [13]: arr = tiled_client.values().last()['primary']['external']['manta-cam2'].read()

In [14]: arr.shape
Out[14]: (200, 1088, 1456)

Here had an exposures_per_event of 1 and 2 respectively, and saving into the same stream.

Going to go ahead and merge.