Companion to #8456

If using babystep to adjust the Z probe offset, the axis will move and the mesh will be updated at the same time, causing a doubling of the Z offset over the rest of the print.

To correct for this, the current Z position would need to be modified in the opposite direction, canceling out the additional Z offset added to the mesh. This would be confusing to users, and moreover it would not be accurate without also taking the current Z fade level and current Z height into account. And in general it would break things.

It might make sense to change the mesh in the case where no babystepping is taking place, but this could be considered an undesirable and "weird" side-effect of changing the zprobe_zoffset, and would only manifest on the next leveled move.

One way to remedy this would be to go back to storing the mesh with zprobe_zoffset included, then subtracting zprobe_zoffset from the returned Z value (i.e., from bilinear_z_offset). Thus, a babystep moving the Z axis up 1mm could subtract 1 from zprobe_zoffset while adding 1 to all mesh Z values, and everything would continue to operate as normal.

Without including the zprobe_zoffset in the z_values there is no simple or safe way to alter the mesh in conjunction with babystepping.

Meanwhile, the delta_height now wants to get on-board, because it might have been established using a probe. The snowball is growing.

So, rather than establish a precedent for tweaking every possible thing that the zprobe_zoffset may have been involved in at an earlier time, thus complicating our documentation and requiring users to be more aware of these hidden traps, this PR removes all side-effects from a change of zprobe_zoffset, and simply prepares the offset for its next use.