Add support for calculating points like mesh_min and mesh_max based on physical bed size

[Luro02]

What will this PR introduce?

This PR extends Kalico with sections for specifying the physical bed size and where the nozzle would have to move, to be over the bed corner:

[printer]
kinematics: corexy
max_velocity: 400
max_accel: 5000
max_z_velocity: 30
max_z_accel: 350
square_corner_velocity: 5.0

bed_size: 300, 300
bed_corner_position: -4.3, -10.8

The properties will then bed used to calculate positions that previously had to be specified by the user.

For example, in the bed_mesh section, the user had to specify the bed_min and bed_max positions, defining the corners of the mesh that should be probed.

With this PR, the user can omit them, and instead specify a margin (how much the mesh should be away from the edges of the bed):

[bed_mesh]
zero_reference_position: 150, 150
speed: 300
horizontal_move_z: 3
margin: 30, 30
probe_count: 30, 30
algorithm: bicubic

The code will then calculate mesh_min and mesh_max based on the defined physical properties and the desired margin.

This PR updates the following sections to take advantage of this feature

• [bed_mesh]
• [quad_gantry_level]
• [safe_z_home]
• [axis_twist_compensation]

In the below section, I have mentioned other sections that could benefit from this feature.
I have a CoreXY Voron 2.4, so I am neither using these sections, nor do I have the
ability to test these on a real machine. That is why I want to leave the implementation up
to future pull requests.

Why is this needed?

In many configuration sections points have to be specified that depend on the position of the bed, the offset of the probe and the physical limits of where the printer can move to:

• bed_mesh
• bed_tilt
• bed_screws
• screws_tilt_adjust
• z_tilt/z_tilt_ng
• quad_gantry_level
• safe_z_home
• axis_twist_compensation

When you change any of the following

• The bed position
• The min_position/max_position reachable on the axis, for example by switching to a different toolhead
• The probe offset

you would have to go through every section and recalculate or update the positions. This is time-consuming, error-prone and can be confusing, because some sections use probe offsets, others not.
PR #500 added the use_probe_xy_offsets option, which allows making certain points relative to the probe. If there is enough space to move, this is not a problem, but consider the following example where
p is the probe and n the nozzle:

+----------------+
|                |
|                |
|                |
|                |
|  p             |
+----------------+
   n

now the offset in x direction is increased:

+----------------+
|                |
|                |
|                |
|                |
|  p             |
+----------------+

   n

The probe point remains the same, but it might not be possible to reach that position anymore, because the nozzle is too far from the bed. The use_probe_xy_offsets helps when the probe offset changes, but it does not have a concept of where the bed is or account for the axis limits, resulting in potential crashes into the bed or move out of bounds errors.

In the PR for the use_probe_xy_offsets, a kalico crew member commented:

So, I think with this, we could add a probe_margin, e.g. the sense radius on beacon.

Then we just have a bed size, and can mesh the safe region based on toolhead min/max plus probe offset plus margin.

#500 (comment)

Suggesting that this feature is desirable.

Checklist

• pr title makes sense
• added a test case if possible
• if new feature, added to the readme
• ci is happy and green
• Add support for Quad Gantry Level
• Add support for Axis Twist
• Add support for calculating bed center in safe_z_home
• Ensure the code does work on different kinematics systems
• Allow keeping aspect ratio if desired
• Axis twist should have the fields initialized for compatibility with external projects like carto