not all numeric TextEntry widget perform the type check

[RoDuth]

Expected behaviour

Entering invalid characters in a numeric field should not be allowed by the GUI

Actual behaviour

Some fields will allow invalid characters (notably Quantity within Accession Editor allows a trailing '+' ,e.g. '10+') which fail on a postgresql database but work on a sqlite one.

Opinions and suggestions

The plus sign was used to infer that the numbers where either fluid or not accurate in some other way (plants that were short lived and self seeding, clumping forming, or planted as a dense hedge, etc.). This sort of data really belongs in the plant record and while it is currently recorded as such in a note having an 'approx' check box could be considered?

---

this and #399 are spin-off from #390.

[mfrasca]

The type check (numeric) is a lot easier to implement than the length check (string, but not longer than n letters). We have three generic callbacks that apply: on_text_entry_changed (for text, and they should be used for Unicode columns), on_numeric_text_entry_changed (it says numeric, but it's really for Integer columns), and on_textbuffer_changed, meant for UnicodeText columns (unbounded length strings)).

• The numeric test is not consistently used for all Integer columns, and this is the cause of this bug and we should go through the code and check that all TextEntry relative to a numeric field get validated with this callback.
• The TextBuffer test only tests that content changed. (this is fine).
• The TextEntry test should be able to ask the widget about the maximum length of the corresponding model field.
  I don't know how to do this, yet, and in principle we might use this callback also on models where the corresponding field is not a database field.

[mfrasca]

I just split the issue, because it's to radically different tasks: one is about adding the check where it's missing, but the check is available, it's just not being consistently used. The other is about programming the checking logic.