REL-726: Template Editing Take 3

Phase I Proposals created by the PIT contain target information, usually retrieved from a catalog like NED or SIMBAD.  These values are stored with impossible precision.  For example, the V mag for target HIP 100:

     <magnitude band="V" system="Vega">8.4399995803833</magnitude>

When the template editor shows this value only the trailing "3833" is shown and the significant part “8.440" is hidden off to the left.  I could simply reposition the text to show the leading digits with `caret.position = 0`, but then what you see in the target component doesn’t match what you see in the template editor and the two editors don't work the same way.

This change will make text template editor fields work like the `JFormattedTextField` used by the target component.  In particular:

* Every edit to a text field is written through to the model immediately instead of waiting for an `EditDone` event.  This matches how all the other text fields in the OT work.
* `EditDone` events no longer try to write through to the model. This prevents a formatted value like "8.440" from being written over the existing 8.439999... value when the user generates `EditDone` by simply tabbing through the field.
* Unlike `FormattedTextField` it doesn’t have to show a default value like 0.00 when a common value across multiple selected template parameters is not available.

To achieve this, I switched from watching `EditDone` events to directly working with the text field’s underlying `Document`.  This is more cumbersome of course.

I think to do better we should stop storing double and float values as fields in software models so that values can be accurately stored and converted to/from text with the desired precision.