apply correction when swtiching from MBL to physical in G28 X

[lrpirlet]

When using Mesh Bed Leveling, with a servo probe, when G28 X is iissued by the slicer, the hot tip MAY drill a hole in the printed part...
See https://github.com/lrpirlet/Marlin/tree/MMBL_2_for_lrp for the complete environment... (sources, configuration and log file).

Please examine the lines 7268..7270 In the Repetier log.
the Z current position is 5.10mm... we add 3.00mm in line 7269... we get 7.33 mm...

Obliviously there is matter to question... The answer is in the fact that the MBL was cancelled and NO CORRECTION WAS APPLIED when switching to physical coordinates.
@epatel Do I have it right when I think that only Z is modified when switching from MBL to physical coordinates?
@Roxy-3D Maybe something you want to take care of...

Note: the number beteewn the time and the debug message is the line number (LINE) in Marlin_main... Source available.

I suggest this PR as the solution... (works for me).

7265 < 18:35:38.731 : N2353 G28 X0*108 
7266 > 18:35:38.746 : echo:N2353 G28 X0*108 
7267 > 18:35:38.746 : 2741 >>> gcode_G28 
7268 > 18:35:41.769 : 1597 setup_for_endstop_or_probe_move > current_position: (112.70, 128.99, 5.10) 
7269 > 18:35:41.769 : 1706 do_probe_raise(3.00) 
7270 > 18:35:41.773 : 1642 do_blocking_move_to: (112.70, 128.99, 7.33) 
7271 > 18:35:42.813 : 2306 >>> homeaxis(0) 
7272 > 18:35:42.817 : 1578 sync_plan_position > current_position: (0.00, 128.99, 7.33) 
7273 > 18:35:47.343 : 1578 sync_plan_position > current_position: (0.00, 128.99, 7.33) 
7274 > 18:35:47.343 : 2351 > endstops.enable(false) 
7275 > 18:35:47.546 : 2361 > endstops.enable(true) 
7276 > 18:35:47.953 : 2374 > TRIGGER ENDSTOP > current_position: (0.00, 128.99, 7.33) 
7277 > 18:35:47.953 : 1445 >>> set_axis_is_at_home(0) 
7278 > 18:35:47.968 : 1523 > home_offset[axis]==0.00 > current_position: (0.00, 128.99, 7.33) 
7279 > 18:35:47.968 : 1530 <<< set_axis_is_at_home(0) 
7280 > 18:35:47.968 : 1578 sync_plan_position > current_position: (0.00, 128.99, 7.33) 
7281 > 18:35:47.984 : 2440 > AFTER set_axis_is_at_home > current_position: (0.00, 128.99, 7.33) 
7282 > 18:35:47.984 : 2463 <<< homeaxis(0) 
7283 > 18:35:47.984 : 2941 > homeX > current_position: (0.00, 128.99, 7.33) 
7284 > 18:35:47.984 : 1578 sync_plan_position > current_position: (0.00, 128.99, 7.33) 
7285 > 18:35:48.000 : 1578 sync_plan_position > current_position: (0.00, 128.99, 8.75) 
7286 > 18:35:48.015 : 1611 clean_up_after_endstop_or_probe_move > current_position: (0.00, 128.99, 4.87) 
7287 > 18:35:48.015 : 3110 <<< gcode_G28 
7288 > 18:35:48.015 : X:0.00 Y:128.99 Z:4.87 E:0.00 Count X: 0 Y:10319 Z:34997 
7289 > 18:35:48.015 : ok 
7290 < 18:35:48.015 : N2354 M104 T0 S0*17 
7291 > 18:35:48.015 : echo:N2354 M104 T0 S0*17 
7292 > 18:35:48.015 : ok 
7293 < 18:35:48.015 : N2355 M140 S0*84 
7294 > 18:35:48.031 : echo:N2355 M140 S0*84 
7295 > 18:35:48.031 : ok 
7296 < 18:35:48.031 : N2356 M84*45 
7297 > 18:35:48.031 : echo:N2356 M84*45 
7298 > 18:35:48.031 : ok 

[thinkyhead]

I think that only Z is modified when switching from MBL to physical coordinates

Correct. This PR definitely seems to fill a hole. I see that everyplace else where mbl.set_active is called, the current position is also updated at the same time.

In other places, it is accounted for that you might be homing to Z_MAX_POS. I don't think we need to do that here, but @epatel can say for sure. Meanwhile, I can merge this now.