Physical sizes for subresolutions

[melissalinkert]

Fixes #3797. Opening as draft for now as this needs work, but I wanted to capture current progress before switching to other tasks.

Following discussion of 9.0.0 with @ome/formats earlier this week, I think I feel better about the idea of calculating physical pixel sizes for subresolutions in the case where resolutions are flattened. We also already have one reader (DicomReader) that reports a different physical pixel size for each flattened resolution; this is because each resolution's size is stored separately (since one resolution per file).

The current state of this pull request adds some minimal API to FormatTools so we don't have to re-implement calculation in each reader, and updates appropriate BSD readers to make use of it. Only readers that need to be updated are ones that meet all 3 criteria:

• make use of pyramids, i.e. set CoreMetadata.resolutionCount to something other than 1
• report a physical pixel size, i.e. call store.setPixelsPhysicalSize*
• represent a format that does not store a separate physical size for each resolution

I expect the following readers would still need to be updated:

• AFIReader
• CellSensReader
• LeicaSCNReader
• NDPIReader
• PyramidTiffReader
• SVSReader
• TissueFAXSReader
• VectraReader
• VentanaReader
• ZeissCZIReader (CZI Incorrect Pixel Physical Size (For pyramidal image series) #4191)

This will require configuration updates for any datasets that make use of the updated readers. I also note that we don't have a .fake example that uses both pyramids and physical sizes, so at least one example of that will need to be added to the test repo.