Radial profiles may allocate huge arrays with tiny pixel spacings #103

Problem

Since #93 (#98), radial_profile bins the pixels by their distance to the center in steps equal to the smallest distance between neighboring pixel centers (_pixel_spacing), and get_radial_profile accumulates them with np.bincount on the bin index. np.bincount allocates one entry per possible bin, from 0 to the largest one, whether it holds pixels or not:

• with a tiny spacing (non-uniform coordinates such as [0, 1e-8, 1, 2, 3], or strongly anisotropic pixels such as dx = 1e-8, dy = 1), a radius of about 5 gives about 5 × 10⁸ bins: two arrays of several GB for a few dozen pixels, and possibly the exhaustion of the available memory;
• pixel centers that coincide (duplicated coordinates, accepted by ImageObj.set_coords) give a zero step: the computation fails with an obscure error ('list' argument must have no negative elements, after divisions by zero).

The bins holding no pixel are already left out of the profile, so that allocating them is useless.

Proposal

• get_radial_profile: accumulate only the bins holding pixels (np.unique(..., return_inverse=True), then np.bincount on the inverse index): memory proportional to the number of pixels, whatever the step, with bit-identical results (same bins, same order of accumulation); a step that is not positive and finite, or a center that is not finite, is refused with an explicit ValueError;
• _pixel_spacing: pixel centers that coincide along an axis are refused with an explicit ValueError (these inputs already failed);
• the contract of radial_profile is unchanged (version 2): results are identical, and only inputs that already failed are refused with a clear message.

Tests: bit-identity with the former implementation on uniform, anisotropic and non-uniform images, bounded memory with a tiny spacing, explicit refusals.

Reported by an independent review of Sigima 1.4 (unreleased).