If voxel sizes were big, code could run into clamping at 1.0f, making it
look like nothing was happening, also even though the "step size" was
taking into account the initial voxels size (only in relative mode,
absolute mode was, well... absolute, no matter what object this was
happening on, also see 5946ea938a).

So previously, a reasonable voxels size could not achieved using this
operator for e.g. a terrain-size mesh.

Now code allows for bigger/smaller meshes to behave predictably.
This is done by storing a reasonable min and max voxel size (this is
taken from the bounding plane which is also displayed to the user),
making the max the length of the longer side of the bounding plane and
the min a fraction of it (based on `VOXEL_SIZE_EDIT_MAX_GRIDS_LINES` --
smaller voxels would not display anyways...)

Based on the above, we can have a reasonable range to base the change on
which is done moving the mouse.
Because this is more predictable than before, we can even remove the
`relative` mode (dont think it makes too much sense now anymore).

@@ -415,3 +406,1 @@
-    d = d * 0.0005f;
-    cd->relative_mode = false;
-  }
+  d *= cd->voxel_size_min * 0.25f;

@@ -516,6 +506,12 @@ static int voxel_size_edit_invoke(bContext *C, wmOperator *op, const wmEvent *ev
     }
   }
 
+  /* Set reasonable min/max voxel sizes to clamp to. */