ValidationTextBox: subclasses return different getValues on invalid

[haysmark]

If you have a NumberTextBox? and enter some letters, getValue returns NaN as expected. If you give a ValidationTextBox? a regexp of d* (basically making it a NumberTextBox?) and enter some letters, getValue still returns the letters, instead of something like undefined like NumberTextBox?.

We should figure out what these textboxes should be returning when the value is invalid because right now it is inconsistent.

[haysmark]

MappedTextBox? seems to suffer the same problem as ValidationTextBox? and also returns the invalid string as-is. You would think MappedTextBox? would return undefined, more so than ValidationTextBox?, because *every* subclass of MappedTextBox? (DateTextBox?, FilteringSelect?, etc.) returns undefined or an equivalent for an invalid value.

[bill]

I'm making an executive decision on this one:

As much as possible, getValue() *should* return an invalid string as-is. It shouldn't change behavior due to a field being required/not-required, invalid/valid. The only exception is when the widget maps the displayed value into another value, and there is no mapping (ex: "foo" for a NumberTextBox or "Japan" for a FilteringSelect of U.S. states), in which case getValue() should return the same thing it returns when the field is blank.

Also, getValue() should always return data of the same type. Either always strings, always numbers, or always Dates, where an empty date is represented as null (see #6827, #6922).

As for MappedTextBox, the reason it returns the string as-is is because the subclass needs to override certain methods. MappedTextBox by itself doesn't do any mapping.

[bill]

(In [13989]) Support required=true/false parameter for FilteringSelect? so that a blank entry in the dropdown list is not necessary. Patch from Mark Hays (IBM, CCLA on file). Fixes #5974 !strict. Also some cleanup so that onChange() and getValue() return "" for when the input field is blank/invalid. (Before I had thought to return null in those cases but "" seems better.) Refs #5919.