Range input behavior

[nomego]

As outlined in #66 for example, users experience the limiting behavior of the range-type columns weird, the fields changing on their own, etc.

I maintain the view the the user should be guided as far as possible, and that omnitable should strive to never show empty result sets.

Available range

When Omnitable is working "locally" with a loaded dataset, it will figure out the available min/max values for any range-type column.
When used as a search tool, "available values" calls can override min/max values with the min/max properties.

Value enforcement

We do set the min/max values for different types of inputs to represent the available range (number, date, datetime-local) but Chrome doesn't really enforce them. When using the "helper" elements, like -/+ for number, or date picker for date, the range is enforced and visually guides the user to select a valid value. But when the user enters numbers or dates in the input fields, it is not enforced the same way.

(In)Valid input

User input should be validated to make sure it can be used to make a sensible filter.

Invalid input has so far been things like:

• Invalid date
• From-value is higher than to-value (100 - 10, 0 - -100)
• From/to-value less than min value
• From/to-value more than max value

We might want to inform the user (where possible) what the min/max values for the filter is.
This might make the behavior less weird.

Handling invalid input

First of all, filtering should not be triggered if the filter is invalid for any reason.
I think it is today, if for example a user inputted date isn't really a valid date.

In addition, we should at least show an error message to the user, saying why the filter is invalid.
We might not be able to do much else in the case of an invalid date.

But we should not "let the user do wrong" and try to help out further.
The other cases, we today try to help out by making sure from-value is at least "min" and to-value is at most "max", and that to-value is same as, or higher than, from-value.
When from-value is higher than to-value, we could switch them.

But this also has very much to do with #60, so we know when we can do these things, after 300ms timeout, after input blur, etc.
Ping @Neovici/uiux