[2.0.x] Make MBL work more like PROBE_MANUALLY

[thinkyhead]

See also #8574

Fix #7912 and Fix #7491 by making MBL's LCD_BED_LEVELING work in the same manner as PROBE_MANUALLY.

[fiveangle]

MBL does not require LCD, so this breaks printers w/o one

Also, this desperately needs a travis test as it comes up like every couple hundred commits 😝

Marlin/src/gcode/bedlevel/mbl/G29.cpp: In static member function 'static void GcodeSuite::G29()':
Marlin/src/gcode/bedlevel/mbl/G29.cpp:93:35: error: 'lcd_wait_for_move' was not declared in this scope
enqueue_and_echo_commands_P(lcd_wait_for_move ? PSTR("G29 S2") : PSTR("G28\nG29 S2"));

[Roxy-3D]

Also, this desperately needs a travis test as it comes up like every hundred commits 😝

I wonder if we could have two sets of Travis tests... And if so... We would put this test into the 'More Complete' set?

[fiveangle]

I think testing with and w/o these should be part of basic tests wherever supported:

• Panel (display + controller)
• SD

The above example illustrates this.

But I agree with you that a more comphrensive set of tests would be nice. I think one that iterates through every example config would catch a lot of regressions that usually take weeks to be worked through in the tracker.

I looked at doing this back in spring but didn't find an easy (e.g. 5 min I spent ;) solution. It's relatively easy to break up the existing tests to parallelize them, but that doesn't really help much when the setup time on the Precise travis instance is between 4 and 10 minutes: it just spins travis resources w/o really lowering the test time.

[Roxy-3D]

I wouldn't even be opposed to making the extended Travis tests User Name related or perhaps even Pull Request number related. If once every 25 pull requests, we do an extended Travis Test... Nothing will go unnoticed for that long.