Fix #min and #max calculations for the widget "step" configuration

Thanks for reporting. The calculations for #min and #max steps are for sure not correct right now.

But I don't think the #min and #max for the "Step" configuration value should be agnostic from the field. A range element is, by definition, an element that *must* have a minimum value and a maximum value. And we don't want to allow a "Step" value that can go over the difference between the maximum and minimum value. Otherwise the final slider element is essentially broken and cannot be interacted with.

For example, if a Number allows for values between 50 and 250, but it has a step value of 500, then you can't really use the slider. It will only allow you to use it's previous value, or 50, if it had no value before.

I see it as, the #min and #max step value should allow for, at the very least, 1 "slide" on the input element.

The #min is actually something we're already calculating just a bit above that code:

    $scale = $this->fieldDefinition->getFieldStorageDefinition()->getSetting('scale');
    $minimum_step = isset($scale) ? "0." . str_repeat("0", $scale - 1) . "1" : 1;

Which is usually 1, unless it's a decimal field, in which case it takes into account how many decimal cases ("scale") the field permits. (So, a field with 2 decimal cases should have a minimum of 0.01, the lowest amount possible within that scale).

For the maximum, we do need some further calculations that I had overlooked. Particularly when a minimum is already set, and it is *not* 0.

I am now calculating to ensure the maximum value allows for at least 1 "slide" of the element, and ensure it cannot go over that.

One edge-case that I found, not related to this specifically, is that having a "Maximum" value in the number field, of a negative number (E.g. -100), but having no minimum set, will break the slider element.

I added a safeguard in the "Step" configuration, to always default to 1 if the $maximum_step is calculated as less than or equal to 0.

However, the problem isn't really in the configuration but on the actual rendered form element. Drupal defaults to a #min of 0 and a #max of 100 in the "range" form element: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21....

But we can't have a minimum of 0, and a maximum of -100. That just breaks the element completely, as it can never have a valid value. You can't interact with it, nor save any form that has that broken element in it.

It's out of scope for this issue, so I'll be opening a separate issue for that. Ideally we prevent the number range slider to be added in those circumstances, as there really is no way for us to have a sensible #min default value, when we're dealing with negative numbers.

I tested my change with a bunch of different situations, and it seems to be working correctly on all cases. So I'm confident this is OK to add to a new Release. But do tell me if you run into any issues please.

This is now available on the 1.0.2 release.