Fix failing regionprop_table for multichannel properties

[jni]

Description

Closes #6860

Use np.shape() to determine a non-object regionprop's shape, so that the
raveling of the array to columns works even for array-likes, such as
tuple-of-arrays. We also coerce the property to a NumPy array when it comes
time to add the data to the columns.

Checklist

• Docstrings for all functions
• Gallery example in ./doc/examples (new features only)
• Benchmark in ./benchmarks, if your changes aren't covered by an existing benchmark
• Unit tests
• Clean style in the spirit of PEP8
• Descriptive commit messages (see below)

For reviewers

• Check that the PR title is short, concise, and will make sense 1 year
  later.
• Check that new functions are imported in corresponding __init__.py.
• Check that new features, API changes, and deprecations are mentioned in
  doc/release/release_dev.rst.
• There is a bot to help automate backporting a PR to an older branch. For
  example, to backport to v0.19.x after merging, add the following in a PR
  comment: @meeseeksdev backport to v0.19.x
• To run benchmarks on a PR, add the run-benchmark label. To rerun, the label
  can be removed and then added again. The benchmark output can be checked in
  the "Actions" tab.

[lagru]

Approving this. Though, it really took me some time and local debugging to comprehend this and follow all the tuple / array / dimension shenanigans. 😅 I'm not sure whether the code seems this complex because

• I'm not really familiar with regionprops,
• it solves a complicated problem or provides a complex API,
• and / or it and the API have grown a bit "messy" over time.

Curious about your perspective on this... :)

[jni]

• I'm not really familiar with regionprops,
• it solves a complicated problem or provides a complex API,
• and / or it and the API have grown a bit "messy" over time.

Probably a bit of all three? 😅 This PR/issue is touching on some funky dimensional maths:

First issue is #3180: basically, using regionprops for downstream data analysis could be complicated and labour-intensive, because each property is a different thing. So, we came up with #3959, which returns a tidy table with one row per property, and every element of the row being simple types. But, how do you fit multidimensional properties, such as the inertia tensor (ndim x ndim array) into a neat column? We decided to instead break it into its constituent elements, and label the columns by the index; so, inertia_tensor-0-0, inertia_tensor-0-1, ..., inertia_tensor-2-2. (for 3D).

Now when we have multichannel data, in the cases where you use intensity image, you get another axis, which was breaking in #6860 because we were getting an unexpected type (a tuple of arrays) instead of the types we had accounted for (an array, or a tuple of floats/ints). By converting to an array it works — we get centroid_weighted-0-0, ..., which means "weighted centroid coordinate on axis 0 using channel 0", and so on.

In the future, we probably want a way to use metadata a bit better — for example, supplying axis_names='zyx', and channel_names=['nuclei', 'membranes'], you could get centroid_weighted-z-nuclei, centroid_weighted-z-membranes, etc. But that's definitely out of scope for this one PR. 😅

Anyway, you should definitely get more familiar with regionprops — in my opinion it's one of the most valuable things we provide now that segmentation is often solved by deep learning frameworks! 😊 And there's still lots of improvements to make to it.